Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
Tom Herbert <tom@herbertland.com> Fri, 06 September 2019 18:21 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C54120073 for <int-area@ietfa.amsl.com>; Fri, 6 Sep 2019 11:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 VsdrVfNASgx7 for <int-area@ietfa.amsl.com>; Fri, 6 Sep 2019 11:21:08 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE4B120046 for <int-area@ietf.org>; Fri, 6 Sep 2019 11:21:07 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id c19so7073896edy.10 for <int-area@ietf.org>; Fri, 06 Sep 2019 11:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Hi1hVtGRYbfS79RfhbCLlk2kmtSdalBv/oyeC6S0v48=; b=K+9UiaUI1z6C0sNQ4bt4s2jpHDijjplJ7Feeh07Nk/jpMrVAML6R/3NaOFop7Mbf1D ycUSihlsml1BS0i+McZ38S2w9otagYxEwsek9UlpXFf2GeYd3IyGIkCxJ8anAb8bi/xB iXnlt8PIj4SEHl3jxZovpRuHqqthx7BN1QlHi6bj8IQBOJ4muDfhXtAaWsBvk/Y3hAPQ geSo2ETOnEmcsEhhxir8l/hBWMq7y8QxBlYnaXXX15QJFSF7fo+t9zh2BD6GK7EbZAUp fXViOpkjwMcpVP6ZUlvc77EfB+G7gFbgLSAiznS01GT7noPtCw1pN8deu0Yrbe5Dwbxv zjoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Hi1hVtGRYbfS79RfhbCLlk2kmtSdalBv/oyeC6S0v48=; b=VnGO180sUAmFTQDaR+pAln94tmvinzTnHO6JVI7dbdVclQLU4BqCaDrdUkV0nNyK/e XH9J/hLfFlcpI7DBCePwtMU6m4Hex0F6RXRQUdiZRA++brBwUUtZgknDRSbVy6eh9Ll5 jTfLJKAJ9Pjh4L2wgL4Ewth+xeORIC9fyg+b1oSWZ+BfCDQx7FdOmVqMa/jmBLCQLuoB JFHpciMblMkqevX5QVVQHOd9+fRdin7EPTBDTgqR2WLen+DQ+0WxQ4mZCYlmOfYx0zzO a6BpB4b3gqEDSP7242HwjNPVIia97lY/ZtA75s/TBhevskakcpou5mSezMbIkoLD9c9U dqrQ==
X-Gm-Message-State: APjAAAU6hSXFpvRNwpZEJINYyJlPEMn+SykSNP1iJtRV4pqvdhxuA3Ye zPDQVNkntmSNEkQP4dzdjxsbN79znzSdfL8Sgi2/2w==
X-Google-Smtp-Source: APXvYqzrIRJAKm8IxCHSfc90NYzboc8Y4Dhb7I0/Xffs9GlYz4mORKeYXWusYt9yHvxgIXDRaLdP+0IPPHPmEIh9P3s=
X-Received: by 2002:aa7:d694:: with SMTP id d20mr3963877edr.226.1567794066241; Fri, 06 Sep 2019 11:21:06 -0700 (PDT)
MIME-Version: 1.0
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com> <163CD364-2975-467A-8925-F114FFD9C422@employees.org>
In-Reply-To: <163CD364-2975-467A-8925-F114FFD9C422@employees.org>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 06 Sep 2019 11:20:54 -0700
Message-ID: <CALx6S37yqj=7LBxPTgE9Vz9P_eAvhfoj7csNn6cz1Wn0YXycQQ@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Bob Hinden <bob.hinden@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, Suresh Krishnan <suresh@kaloom.com>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/JtvjIUdl8OCl3YUMkjGy6qgG3g4>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 18:21:11 -0000
On Thu, Sep 5, 2019 at 11:33 PM Ole Troan <otroan@employees.org> wrote: > > Bob, et al, > > I have two issues with this text. > > 1) It introduces something new and undescribed in paragraph 2. > "unless they also include mechanisms to detect that IP fragmentation isn't working > reliably." > That seems like hand-waving to me. Suggest deleting. > > 2) Paragraph 4: > "The risks of IP fragmentation can also be mitigated > through the use of encapsulation, e.g., by transmitting IP fragments > as payloads." > > This seems like proposing new unspecified solutions with it's own set > of considerations. IP fragmentation is a general solution to all hosts, > encapsulation is certainly not in every host, and has different > properties with regards to NAT traversal etc. Also if encapsulation > was the answer, other segmentation / reassembly that were tunnel > specific could be developed. Regardless this also amounts of hand-waving > and doesn't seem to offer any advice that can be heeded now. > And of course encapsulation can also exacerbate the problem > by increasing packet size. > Suggest deletion. > Ole, This also makes the implicit and seemingly unproven assumption that encapsulation is less fragile than IP fragmentation on the Internet. Without the data that shows otherwise, I don't believe there is any basis to say that encapsulation is generally a viable alternative. Also, I would note that there was similar text in early versions of RFC8200 that encapsulation could be used as a method of allowing extension header insertion. That text was taken out because encapsulation is not sufficiently standardized or ubiquitous to be considered a direct replacement for an IP network layer protocol function. The same is true here, encapsulation is not a drop-in replacement for IP fragmentation. Tom > New text: > > 6.1. For Application and Protocol Developers > > Developers SHOULD NOT develop new protocols or applications that rely > on IP fragmentation. When a new protocol or application is deployed > in an environment that does not fully support IP fragmentation, it > SHOULD operate correctly, either in its default configuration or in a > specified alternative configuration. > > While there may be controlled environments where IP fragmentation > works reliably, this is a deployment issue and can not be known to > someone developing a new protocol or application. It is not > recommended that new protocols or applications be developed that rely > on IP fragmentation. Protocols and applications that rely on IP > fragmentation will work less reliably on the Internet. > > Legacy protocols that depend upon IP fragmentation SHOULD be updated > to break that dependency. However, in some cases, there may be no > viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- > in-IP encapsulation). Applications and protocols cannot necessarily > know or control whether they use lower layers or network paths that > rely on such fragmentation. In these cases, the protocol will > continue to rely on IP fragmentation but should only be used in > environments where IP fragmentation is known to be supported. > > Protocols may be able to avoid IP fragmentation by using a > sufficiently small MTU (e.g. The protocol minimum link MTU), > disabling IP fragmentation, and ensuring that the transport protocol > in use adapts its segment size to the MTU. Other protocols may > deploy a sufficiently reliable PMTU discovery mechanism > (e.g.,PLMPTUD). > > UDP applications SHOULD abide by the recommendations stated in > Section 3.2 of [RFC8085]. > > > Cheers, > Ole > > > On 6 Sep 2019, at 06:05, Bob Hinden <bob.hinden@gmail.com> wrote: > > > > Hi, > > > > Joe and I talked off list. The result is below. Changes were to add a sentence in the forth and fifth paragraphs. > > > > Please review. > > > > Bob > > > > ---------- > > > > 6.1. For Application and Protocol Developers > > > > Developers SHOULD NOT develop new protocols or applications that rely > > on IP fragmentation. When a new protocol or application is deployed > > in an environment that does not fully support IP fragmentation, it > > SHOULD operate correctly, either in its default configuration or in a > > specified alternative configuration. > > > > While there may be controlled environments where IP fragmentation > > works reliably, this is a deployment issue and can not be known to > > someone developing a new protocol or application. It is not > > recommended that new protocols or applications be developed that rely > > on IP fragmentation. Protocols and applications that rely on IP > > fragmentation will work less reliably on the Internet unless they > > also include mechanisms to detect that IP fragmentation isn't working > > reliably. > > > > Legacy protocols that depend upon IP fragmentation SHOULD be updated > > to break that dependency. However, in some cases, there may be no > > viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- > > in-IP encapsulation). Applications and protocols cannot necessarily > > know or control whether they use lower layers or network paths that > > rely on such fragmentation. In these cases, the protocol will > > continue to rely on IP fragmentation but should only be used in > > environments where IP fragmentation is known to be supported. > > > > Protocols may be able to avoid IP fragmentation by using a > > sufficiently small MTU (e.g. The protocol minimum link MTU), > > disabling IP fragmentation, and ensuring that the transport protocol > > in use adapts its segment size to the MTU. Other protocols may > > deploy a sufficiently reliable PMTU discovery mechanism > > (e.g.,PLMPTUD). The risks of IP fragmentation can also be mitigated > > through the use of encapsulation, e.g., by transmitting IP fragments > > as payloads. > > > > UDP applications SHOULD abide by the recommendations stated in > > Section 3.2 of [RFC8085]. > > > > ————— > > > > > > > >> On Sep 5, 2019, at 6:18 PM, Joe Touch <touch@strayalpha.com> wrote: > >> > >> Although this is close, it misses the mark a little on the issue that > >> the app may not actually have any control here - or know how or when to > >> reduce its MTU. That might be a minor point to add, but is worth adding. > >> This isn't just an app layer issue. > >> > >> Joe > >> > >> On 9/5/2019 4:45 PM, Ron Bonica wrote: > >>> Bob, > >>> > >>> I think that this is a close to consensus as we are going to get. > >>> > >>> Ron > >>> > >>> > >>> Juniper Business Use Only > >>> > >>> -----Original Message----- > >>> From: Bob Hinden <bob.hinden@gmail.com> > >>> Sent: Thursday, September 5, 2019 2:29 PM > >>> To: int-area@ietf.org > >>> Cc: Bob Hinden <bob.hinden@gmail.com>; Alissa Cooper <alissa@cooperw.in>; IESG <iesg@ietf.org>; Joel Halpern <joel.halpern@ericsson.com>; draft-ietf-intarea-frag-fragile@ietf.org; intarea-chairs@ietf.org; Suresh Krishnan <suresh@kaloom.com> > >>> Subject: Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile > >>> > >>> Hi, > >>> > >>> Based on the discussion, I would like to propose to see if this will resolve the issues raised. It attempts to cover the issues raised. > >>> > >>> The full section 6.1 is included below, but only the last sentence in the second paragraph changed. > >>> > >>> Please review and comment. > >>> > >>> Thanks, > >>> Bob > >>> > >>> > >>> > >>> 6.1. For Application and Protocol Developers > >>> > >>> Developers SHOULD NOT develop new protocols or applications that rely > >>> on IP fragmentation. When a new protocol or application is deployed > >>> in an environment that does not fully support IP fragmentation, it > >>> SHOULD operate correctly, either in its default configuration or in a > >>> specified alternative configuration. > >>> > >>> While there may be controlled environments where IP fragmentation > >>> works reliably, this is a deployment issue and can not be known to > >>> someone developing a new protocol or application. It is not > >>> recommended that new protocols or applications be developed that rely > >>> on IP fragmentation. Protocols and applications that rely on IP > >>> fragmentation will work less reliably on the Internet unless they > >>> also include mechanisms to detect that IP fragmentation isn't working > >>> reliably. > >>> > >>> Legacy protocols that depend upon IP fragmentation SHOULD be updated > >>> to break that dependency. However, in some cases, there may be no > >>> viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP- > >>> in-IP encapsulation). In these cases, the protocol will continue to > >>> rely on IP fragmentation but should only be used in environments > >>> where IP fragmentation is known to be supported. > >>> > >>> Protocols may be able to avoid IP fragmentation by using a > >>> sufficiently small MTU (e.g. The protocol minimum link MTU), > >>> disabling IP fragmentation, and ensuring that the transport protocol > >>> in use adapts its segment size to the MTU. Other protocols may > >>> deploy a sufficiently reliable PMTU discovery mechanism > >>> (e.g.,PLMPTUD). > >>> > >>> UDP applications SHOULD abide by the recommendations stated in > >>> Section 3.2 of [RFC8085]. > >>> > >>> _______________________________________________ > >>> Int-area mailing list > >>> Int-area@ietf.org > >>> https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
- [Int-area] Alissa Cooper's No Objection on draft-… Alissa Cooper via Datatracker
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Tom Herbert
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Tom Herbert
- Re: [Int-area] Alissa Cooper's No Objection on dr… Bob Hinden
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Bob Hinden
- Re: [Int-area] Alissa Cooper's No Objection on dr… Tom Herbert
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Bob Hinden
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Ole Troan
- Re: [Int-area] Alissa Cooper's No Objection on dr… Tom Herbert
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Black, David
- Re: [Int-area] Alissa Cooper's No Objection on dr… Bob Hinden
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Ole Troan
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Bob Hinden
- Re: [Int-area] Alissa Cooper's No Objection on dr… Ole Troan
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Ron Bonica
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fred Baker
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fred Baker
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Tom Herbert
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fernando Gont
- Re: [Int-area] Alissa Cooper's No Objection on dr… Templin (US), Fred L
- Re: [Int-area] Alissa Cooper's No Objection on dr… Warren Kumari
- [Int-area] Discussion about Section 6.1 in draft-… Bob Hinden
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Bob Hinden
- Re: [Int-area] Discussion about Section 6.1 in dr… Joel Halpern
- Re: [Int-area] Discussion about Section 6.1 in dr… Tom Herbert
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Bob Hinden
- Re: [Int-area] Discussion about Section 6.1 in dr… Bob Hinden
- Re: [Int-area] Discussion about Section 6.1 in dr… Warren Kumari
- Re: [Int-area] Discussion about Section 6.1 in dr… Ron Bonica
- Re: [Int-area] Discussion about Section 6.1 in dr… Tom Herbert
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Bob Hinden
- Re: [Int-area] Discussion about Section 6.1 in dr… Ron Bonica
- Re: [Int-area] Discussion about Section 6.1 in dr… Ole Troan
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Ole Troan
- Re: [Int-area] Discussion about Section 6.1 in dr… Tom Herbert
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Ole Troan
- Re: [Int-area] Discussion about Section 6.1 in dr… Ole Troan
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Tom Herbert
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Tom Herbert
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Ole Troan
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Bob Hinden
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Fernando Gont
- Re: [Int-area] Discussion about Section 6.1 in dr… Bob Hinden
- Re: [Int-area] Alissa Cooper's No Objection on dr… Fred Baker
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Brian E Carpenter
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Brian E Carpenter
- Re: [Int-area] Alissa Cooper's No Objection on dr… Joe Touch
- Re: [Int-area] Alissa Cooper's No Objection on dr… Brian E Carpenter
- Re: [Int-area] Discussion about Section 6.1 in dr… Fernando Gont
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Geoff Huston
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Bob Hinden
- Re: [Int-area] Discussion about Section 6.1 in dr… Brian E Carpenter
- Re: [Int-area] Discussion about Section 6.1 in dr… Ron Bonica
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Ole Troan
- Re: [Int-area] Discussion about Section 6.1 in dr… Fred Baker
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Templin (US), Fred L
- Re: [Int-area] Discussion about Section 6.1 in dr… Joe Touch
- Re: [Int-area] Discussion about Section 6.1 in dr… Fred Baker