From philip_matthews@magma.ca Wed Jan 1 19:26:45 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E561AE141 for ; Wed, 1 Jan 2014 19:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmkWV_eryb6l for ; Wed, 1 Jan 2014 19:26:42 -0800 (PST) Received: from mail-07.primus.ca (smtp3.primus.ca [209.216.129.203]) by ietfa.amsl.com (Postfix) with ESMTP id CAB401AE00D for ; Wed, 1 Jan 2014 19:26:42 -0800 (PST) Received: from bas2-kanata16-2925341485.dsl.bell.ca ([174.93.43.45] helo=[192.168.3.8]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VyYvU-0007xV-31; Wed, 01 Jan 2014 22:26:29 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20131231102157.3A1BB7FC175@rfc-editor.org> Date: Wed, 1 Jan 2014 22:26:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <135FBFDF-1D88-4301-82FB-78FEB78D8251@magma.ca> References: <20131231102157.3A1BB7FC175@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - bas2-kanata16-2925341485.dsl.bell.ca ([192.168.3.8]) [174.93.43.45] Cc: Rohan Mahy , Behave WG , Jonathan Rosenberg , Dave Thaler , mls.ietf@gmail.com, spencerdawkins.ietf@gmail.com, Dan Wing , toyvenu.tech@gmail.com Subject: Re: [BEHAVE] [Editorial Errata Reported] RFC5766 (3854) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 03:26:45 -0000 I believe that Venu is correct: the value should be 16,384 (and not = 16,383 as the RFC states). This was probably my error. - Philip On 2013-12-31, at 5:21 , RFC Errata System wrote: > The following errata report has been submitted for RFC5766, > "Traversal Using Relays around NAT (TURN): Relay Extensions to Session = Traversal Utilities for NAT (STUN)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5766&eid=3D3854 >=20 > -------------------------------------- > Type: Editorial > Reported by: Venu >=20 > Section: 11 >=20 > Original Text > ------------- > 0x4000 through 0x7FFF: These values are the allowed channel >=20 > numbers (16,383 possible values). >=20 > Corrected Text > -------------- > 0x4000 through 0x7FFF: These values are the allowed channel >=20 > numbers (16,384 possible values). >=20 > Notes > ----- > Section 11.2: The channel number is in the range 0x4000 through 0x7FFE >=20 > (inclusive); >=20 > Since both the values are inclusive it should be 16384 =3D = (0x7FFF-0x4000 + 1) >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5766 (draft-ietf-behave-turn-16) > -------------------------------------- > Title : Traversal Using Relays around NAT (TURN): Relay = Extensions to Session Traversal Utilities for NAT (STUN) > Publication Date : April 2010 > Author(s) : R. Mahy, P. Matthews, J. Rosenberg > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 From tom.taylor.stds@gmail.com Tue Jan 21 05:43:50 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A17A1A010C for ; Tue, 21 Jan 2014 05:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rnegdz2jJRay for ; Tue, 21 Jan 2014 05:43:49 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 15DC41A00EC for ; Tue, 21 Jan 2014 05:43:49 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id tp5so3462292ieb.19 for ; Tue, 21 Jan 2014 05:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=OiKBUlhASFy01B2r3700+j7qHQ2kMopRjPaW+PRh3IM=; b=jOWHllH8xklrMkXH0VCbeSTuicslIwd1yrO6e1shYOIeKu6crhpxOcxWqMywiGwZAo dppTuZR/SmufbeOb+uZytJbTuaoAB4jh9LI23+lLJOxhHxQ8ARdXNh7deyj54qRrRIuq sc3aO5CCYQYtq6QXMNqDACLR76ksSmcrHPqoMHzL6Rl8YS1o4PiH+CbjWW1+g2PeLG4f nChsgQkPidYsO00HTjQcAHpT/d+maW7LrV8MvMAktHEwLhaBx3G+3tjiwZWx2CXW2RD1 nOcNlNWdpFmnESqF8ZjoeNtfjNsNNmJTWDkmSTaaNVV1XN/gskGwr8DJd4nuvkMuIOkl gUGQ== X-Received: by 10.50.225.105 with SMTP id rj9mr15393816igc.19.1390311828801; Tue, 21 Jan 2014 05:43:48 -0800 (PST) Received: from [192.168.1.69] ([64.56.225.169]) by mx.google.com with ESMTPSA id d18sm12003910igz.0.2014.01.21.05.43.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jan 2014 05:43:48 -0800 (PST) Message-ID: <52DE7991.3000800@gmail.com> Date: Tue, 21 Jan 2014 08:43:45 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Single-Purpose NATs, Multi-Purpose NATs, and NAT-related standards X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:43:50 -0000 I am trying to work through the issue of how general a NAT the SYSLOG logging document should provide for. This also affects the MIB (and IPFIX) documents, since we are trying to keep them synchronized. The issue seems to come to a head when considering the question of address pools. The MIB shows the following: 1. An address pool can only belong to one realm. See natPoolRealm in the natPoolTable. 2. A subscriber is mapped to only one address pool. See natSubscriberPool in natSubscribersTable. Between these two restrictions, we have the following implication: a given subscriber can have sessions with only one external realm at a time (that is, only one realm external to the realm in which the subscriber lies). I can think of use cases where this makes for a viable product: -- traditional NAT44 where everything goes between one internal realm and the rest of the world in the other. NAT64 or NAT46 are similar cases. -- DS-Lite AFTR, where the DS-Lite subscribers are the internal realm and the global IPv4 network is the external realm. On the other hand, I see use cases where the subscriber will want to connect to multiple realms, each having its own address pool by necessity because it has its own numbering space: -- NAT4x or NAT6x, connecting single-stack subscribers to both the IPv4 and IPv6 external world. -- a NAT serving multiple enterprises, each having its own realm with overlapping numbering space, distinguished by ingress interface identifiers, where the enterprises want to communicate with each other as well as the outside world. The question is whether the MIB and logging documents should be able to handle these more general cases. If so, it has to be possible for a subscriber to be mapped into more than one address pool at once. Comments? Tom Taylor From simon.perreault@viagenie.ca Tue Jan 21 06:35:13 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10B11A0151 for ; Tue, 21 Jan 2014 06:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlsG60THwznB for ; Tue, 21 Jan 2014 06:35:07 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88C8E1A0149 for ; Tue, 21 Jan 2014 06:35:07 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5676940367 for ; Tue, 21 Jan 2014 09:35:07 -0500 (EST) Message-ID: <52DE859B.8020901@viagenie.ca> Date: Tue, 21 Jan 2014 09:35:07 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: behave@ietf.org References: <52DE7991.3000800@gmail.com> In-Reply-To: <52DE7991.3000800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Single-Purpose NATs, Multi-Purpose NATs, and NAT-related standards X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:35:13 -0000 Le 2014-01-21 08:43, Tom Taylor a écrit : > I am trying to work through the issue of how general a NAT the SYSLOG > logging document should provide for. This also affects the MIB (and > IPFIX) documents, since we are trying to keep them synchronized. > > The issue seems to come to a head when considering the question of > address pools. The MIB shows the following: > > 1. An address pool can only belong to one realm. See natPoolRealm in the > natPoolTable. I can't imagine an address pool belonging to multiple realms. I could imagine a "set of pools" kind of thing that would simply be an enumeration of pools. But I don't see a use case of it (see below). > 2. A subscriber is mapped to only one address pool. See > natSubscriberPool in natSubscribersTable. > > Between these two restrictions, we have the following implication: a > given subscriber can have sessions with only one external realm at a > time (that is, only one realm external to the realm in which the > subscriber lies). > > I can think of use cases where this makes for a viable product: > > -- traditional NAT44 where everything goes between one internal realm > and the rest of the world in the other. NAT64 or NAT46 are similar cases. > > -- DS-Lite AFTR, where the DS-Lite subscribers are the internal realm > and the global IPv4 network is the external realm. > > On the other hand, I see use cases where the subscriber will want to > connect to multiple realms, each having its own address pool by > necessity because it has its own numbering space: > > -- NAT4x or NAT6x, connecting single-stack subscribers to both the IPv4 > and IPv6 external world. > > -- a NAT serving multiple enterprises, each having its own realm with > overlapping numbering space, distinguished by ingress interface > identifiers, where the enterprises want to communicate with each other > as well as the outside world. Another use case: when accessing ISP internal services (e.g. video on demand), a different external realm would be used, and therefore a different pool as well. > The question is whether the MIB and logging documents should be able to > handle these more general cases. If so, it has to be possible for a > subscriber to be mapped into more than one address pool at once. We have to be extremely careful with language here. Let's go back to the MIB definition: natSubscriberPool OBJECT-TYPE SYNTAX Unsigned32 (0|1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "External address pool to which this subscriber belongs, or zero if the subscriber does not belong to any pool." ::= { natSubscribersEntry 7 } The word "belong" has been very carefully chosen. Its meaning is undefined in IETF documents as far as I know. Therefore it would be up to a particular implementation to define what "belong" means. A subscriber "belonging" to one particular pool does not preclude NAT mappings existing or being created for this subscriber with an external address taken from a pool different from the one to which the subscriber belongs. The usefulness of natSubscriberPool resides in the fact that fact that an implementation may maintain in its state memory an explicit association between subscriber and pool. This piece of NAT state can thus be reported through natSubscriberPool. New mappings would usually be allocated from that pool, but on edge conditions an implementation could decide to do weird things like borrow ports from a different pool, switch a subscriber's pool, change a pool's definition, or whatever else. So I see two viable options: 1. Remove natSubscriberPool. 2. Keep natSubscriberPool and add text saying that: - "belong" is undefined. - Mappings for this subscriber may exist or even be created with external addresses taken from a different pool. - The value zero can also mean that a subscriber belongs to multiple pools. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom.taylor.stds@gmail.com Tue Jan 21 12:07:03 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABBD1A038C for ; Tue, 21 Jan 2014 12:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpU0xJw6fwqb for ; Tue, 21 Jan 2014 12:07:02 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 042311A01B9 for ; Tue, 21 Jan 2014 12:07:01 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id tq11so8637525ieb.40 for ; Tue, 21 Jan 2014 12:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q+EdLoQbgOaL5bCK8gT/UNYV2Askje4dYY2U3oZYs1M=; b=G5XllIi94ruQLsQYSd1Z1AwtjOn6SjpTL4myh1gegcQ/sMc4ePMiOCuZiKflmUhXuF jz/xZfh4Fuozigz3s5WgQsdkuoCAjYIYqStHXzIX5WwhAtcXWmKsDON5xsqy/KN5BpDw 9ALUYeMJOhn0ERzLP1kUiFLf1SVYlcbmdnCbM+ND/LydqZEepslOoCA0oBk4mfRwTjXG H/p8V9k/4Hl3p3fI9B70X/0UcVrRrquq7yGC6KZ0kv4l5lsRypXeNQKOEN0kBSFj8AY3 YAiGH55Gfb4s9lMVFG1rQmxyQDion7+oh+yv8/22PQ3bsFFLWweuDpjwv7tPWlssFKzW b2VQ== X-Received: by 10.43.150.18 with SMTP id km18mr11571276icc.43.1390334810635; Tue, 21 Jan 2014 12:06:50 -0800 (PST) Received: from [192.168.1.69] ([64.56.225.169]) by mx.google.com with ESMTPSA id fk5sm14703506igb.9.2014.01.21.12.06.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jan 2014 12:06:50 -0800 (PST) Message-ID: <52DED356.3080406@gmail.com> Date: Tue, 21 Jan 2014 15:06:46 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: behave@ietf.org References: <52DE7991.3000800@gmail.com> <52DE859B.8020901@viagenie.ca> In-Reply-To: <52DE859B.8020901@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Single-Purpose NATs, Multi-Purpose NATs, and NAT-related standards X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:07:04 -0000 On 21/01/2014 9:35 AM, Simon Perreault wrote: > Le 2014-01-21 08:43, Tom Taylor a écrit : >> I am trying to work through the issue of how general a NAT the SYSLOG >> logging document should provide for. This also affects the MIB (and >> IPFIX) documents, since we are trying to keep them synchronized. >> >> The issue seems to come to a head when considering the question of >> address pools. The MIB shows the following: >> >> 1. An address pool can only belong to one realm. See natPoolRealm in the >> natPoolTable. > > I can't imagine an address pool belonging to multiple realms. [PTT] I had no intention of questioning this one. > > I could imagine a "set of pools" kind of thing that would simply be an > enumeration of pools. But I don't see a use case of it (see below). > >> 2. A subscriber is mapped to only one address pool. See >> natSubscriberPool in natSubscribersTable. >> >> Between these two restrictions, we have the following implication: a >> given subscriber can have sessions with only one external realm at a >> time (that is, only one realm external to the realm in which the >> subscriber lies). >> >> I can think of use cases where this makes for a viable product: >> >> -- traditional NAT44 where everything goes between one internal realm >> and the rest of the world in the other. NAT64 or NAT46 are similar cases. >> >> -- DS-Lite AFTR, where the DS-Lite subscribers are the internal realm >> and the global IPv4 network is the external realm. >> >> On the other hand, I see use cases where the subscriber will want to >> connect to multiple realms, each having its own address pool by >> necessity because it has its own numbering space: >> >> -- NAT4x or NAT6x, connecting single-stack subscribers to both the IPv4 >> and IPv6 external world. >> >> -- a NAT serving multiple enterprises, each having its own realm with >> overlapping numbering space, distinguished by ingress interface >> identifiers, where the enterprises want to communicate with each other >> as well as the outside world. > > Another use case: when accessing ISP internal services (e.g. video on > demand), a different external realm would be used, and therefore a > different pool as well. > >> The question is whether the MIB and logging documents should be able to >> handle these more general cases. If so, it has to be possible for a >> subscriber to be mapped into more than one address pool at once. > > We have to be extremely careful with language here. > > Let's go back to the MIB definition: > > natSubscriberPool OBJECT-TYPE > SYNTAX Unsigned32 (0|1..4294967295) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "External address pool to which this subscriber belongs, or > zero if the subscriber does not belong to any pool." > ::= { natSubscribersEntry 7 } > > The word "belong" has been very carefully chosen. Its meaning is > undefined in IETF documents as far as I know. Therefore it would be up > to a particular implementation to define what "belong" means. > > A subscriber "belonging" to one particular pool does not preclude NAT > mappings existing or being created for this subscriber with an external > address taken from a pool different from the one to which the subscriber > belongs. > > The usefulness of natSubscriberPool resides in the fact that fact that > an implementation may maintain in its state memory an explicit > association between subscriber and pool. This piece of NAT state can > thus be reported through natSubscriberPool. New mappings would usually > be allocated from that pool, but on edge conditions an implementation > could decide to do weird things like borrow ports from a different pool, > switch a subscriber's pool, change a pool's definition, or whatever else. > > So I see two viable options: > > 1. Remove natSubscriberPool. > > 2. Keep natSubscriberPool and add text saying that: > - "belong" is undefined. > - Mappings for this subscriber may exist or even be created with > external addresses taken from a different pool. > - The value zero can also mean that a subscriber belongs to multiple pools. > > Simon [PTT] I'd go for (1) removing natSubscriberPool. Any default is an implementation issue. Tom From simon.perreault@viagenie.ca Tue Jan 21 12:15:41 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4511A01B9 for ; Tue, 21 Jan 2014 12:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emm1eDJaVOMz for ; Tue, 21 Jan 2014 12:15:39 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9F1A0127 for ; Tue, 21 Jan 2014 12:15:39 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E0CA140367 for ; Tue, 21 Jan 2014 15:15:38 -0500 (EST) Message-ID: <52DED56A.8080008@viagenie.ca> Date: Tue, 21 Jan 2014 15:15:38 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: behave@ietf.org References: <52DE7991.3000800@gmail.com> <52DE859B.8020901@viagenie.ca> <52DED356.3080406@gmail.com> In-Reply-To: <52DED356.3080406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Single-Purpose NATs, Multi-Purpose NATs, and NAT-related standards X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:15:41 -0000 Le 2014-01-21 15:06, Tom Taylor a écrit : >> So I see two viable options: >> >> 1. Remove natSubscriberPool. >> >> 2. Keep natSubscriberPool and add text saying that: >> - "belong" is undefined. >> - Mappings for this subscriber may exist or even be created with >> external addresses taken from a different pool. >> - The value zero can also mean that a subscriber belongs to multiple >> pools. > > [PTT] I'd go for (1) removing natSubscriberPool. Any default is an > implementation issue. Consider it done. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Jan 24 12:31:47 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DE91A0060 for ; Fri, 24 Jan 2014 12:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnO86GL-Cu8z for ; Fri, 24 Jan 2014 12:31:45 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21F1A004E for ; Fri, 24 Jan 2014 12:31:45 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 38F5B403F8 for ; Fri, 24 Jan 2014 15:31:44 -0500 (EST) Message-ID: <52E2CDAF.8020409@viagenie.ca> Date: Fri, 24 Jan 2014 15:31:43 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "behave@ietf.org" References: <20140124202212.817.85315.idtracker@ietfa.amsl.com> In-Reply-To: <20140124202212.817.85315.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140124202212.817.85315.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Fwd: New Version Notification for draft-ietf-behave-nat-mib-11.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:31:47 -0000 FYI, a new revision of the NAT MIB draft has been posted. Summary of the changes: - Reworked the subscriber identifier types. - Reverted the table of quotas. Quota drops is a single counter again. - Added an index column to the table of subscribers. - Added a subscriber index column to the mapping tables. - Removed natSubscriberPool as it was under-specified. We now know of no open issues. Simon -------- Message original -------- A new version of I-D, draft-ietf-behave-nat-mib-11.txt has been successfully submitted by Simon Perreault and posted to the IETF repository. Name: draft-ietf-behave-nat-mib Revision: 11 Title: Definitions of Managed Objects for Network Address Translators (NAT) Document date: 2014-01-24 Group: Individual Submission Pages: 91 URL: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-mib-11.txt Status: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib/ Htmlized: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-11 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-11 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. This document obsoletes RFC 4008. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From tom.taylor.stds@gmail.com Fri Jan 24 18:16:57 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9A41A045F for ; Fri, 24 Jan 2014 18:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh0nt6ysFMU7 for ; Fri, 24 Jan 2014 18:16:55 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2F1A045B for ; Fri, 24 Jan 2014 18:16:55 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id at1so3755292iec.36 for ; Fri, 24 Jan 2014 18:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=0X3FesSz5ieWbD7w9GxkqD/AdWG2ZJ13bj8ADOpJWKY=; b=AlNaj79T5NAKaURjgLSdkN20B3giHbnHV8XpiwY49d70gFUVAaBWPCnHbUaWwY8loR zhNYfssGkG90eIET2ggWdgrj8O7nsUytICNuYP9R8e50B0WgJjJGlve4q3g39IbDNosc Ajg1I30Pj/yf8qpU8pc0kFfcw3vmiDapfCeFwixBPV5x0DNLJO8oowD3RWJbZuy+yYUc LZQSqIlPUQXsbtwIcnG5aBNyDq/jhul7CrFw6N5HgIkB7Apn/nV4lMUf7Itjem87ys28 Cbzdy4wlyB1Cx/G7MIEt9s3GHDZRkfSjVhhCSThhYHTT71aF1fVa7htV4EBxviIzkqqc EvzQ== X-Received: by 10.50.159.194 with SMTP id xe2mr7591289igb.13.1390616213948; Fri, 24 Jan 2014 18:16:53 -0800 (PST) Received: from [192.168.1.69] ([64.56.225.169]) by mx.google.com with ESMTPSA id kb10sm15127470igb.6.2014.01.24.18.16.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 18:16:53 -0800 (PST) Message-ID: <52E31E90.1010105@gmail.com> Date: Fri, 24 Jan 2014 21:16:48 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] draft-ietf-behave-syslog-nat-logging-06.txt submitted X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 02:16:57 -0000 This should be the final update pending comments. The main substantive change from the previous version was to back off a bit from the idea of the generalized internal address. Instead, the actual packet source address is presented, and if that is not enough to identify the subscriber unambiguously, additional data (interface list, VLAN identifier, VPN identifier, or encapsulating IPv6 address) is presented. There are a lot of editorial changes: -- resource allocation events presented in the more logical order: address mapping, address and port mapping (note the latest terminology), then session mapping -- maintenance-related events sorted out to group threshold events in one section, limit events in another -- parameters listed in related groups rather than alphabetical order, and presentation of parameter coding much simplified -- parameter names once more changed to be more logical (last time, I promise). Added a table relating the parameters to their MIB equivalents where applicable. The whole document is consistent with draft-ietf-behave-nat-mib-11, just submitted. Tom Taylor From georgehanes@hushmail.com Thu Jan 30 14:04:57 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21A91A04DA for ; Thu, 30 Jan 2014 14:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.535, SPF_HELO_NEUTRAL=0.112, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Oq7deC8-vct for ; Thu, 30 Jan 2014 14:04:56 -0800 (PST) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) by ietfa.amsl.com (Postfix) with ESMTP id C78241A04B2 for ; Thu, 30 Jan 2014 14:04:56 -0800 (PST) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) by smtp3.hushmail.com (Postfix) with SMTP id 8F595E0246 for ; Thu, 30 Jan 2014 22:04:53 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Thu, 30 Jan 2014 22:04:53 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 799206018A; Thu, 30 Jan 2014 22:04:53 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 30 Jan 2014 17:04:53 -0500 To: behave@ietf.org From: georgehanes@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20140130220453.799206018A@smtp.hushmail.com> Subject: [BEHAVE] Be cautious of this computer science conference X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 22:11:03 -0000 Be cautious of this computer science conference If you have any thought of attending the world’s biggest f-a-k-e conference in computer science http://www.world-academy-of-science.org you should visit any websites below https://sites.google.com/site/worlddump1 or https://sites.google.com/site/dumpconf https://sites.google.com/site/moneycomp1 https://sites.google.com/site/worlddump4 The organizer of this conference is H-amid A-rabnia http://www.cs.uga.edu/~hra a professor from University of Georgia, Athens, US. He already earned millions of dollars from the registration fee. He recently started a new conference CSCI due to his hunger for money http://www.americancse.org He did not reveal the reviews and reviewers' information for all the papers he received, despite repeated requests and challenges. The reason for his failure is there are no reviews and reviewers and he just cheated the research community for more than a decade by announcing that each draft paper is reviewed by two experts. We challenge him to publish these details at the conference website. Where are your experts? Where are your reviews? Soon he comes up with a story announcing that he lost all the information having reviews and reviewers because of computer crash or theft. DBLP stopped indexing these conferences since 2011 and displayed an explicit message; "The DBLP Advisory Board decided to discontinue indexing of this conference series". Visit http://www.informatik.uni-trier.de/~ley/db/conf/biocomp/index.html as a sample. He was forced to remove his name, the university of Georgia name, and university of Georgia email address from the conference’s contact page because the University has banned him from doing that. Do not spoil your resume by publishing in this conference. Apologies for posting to multiple mailing lists. Spreading the news is the only way to stop this conference from harming innocent researchers. Respectfully, Many researchers cheated by these conferences