Re: I-D affects another or work in ietf groups

Eric Burger <eburger-l@standardstrack.com> Sat, 09 February 2013 12:14 UTC

Return-Path: <eburger-l@standardstrack.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB0B21F8AB6 for <ietf@ietfa.amsl.com>; Sat, 9 Feb 2013 04:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sGbvfBKY-8t for <ietf@ietfa.amsl.com>; Sat, 9 Feb 2013 04:14:47 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9459D21F8AB4 for <ietf@ietf.org>; Sat, 9 Feb 2013 04:14:47 -0800 (PST)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:53322 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger-l@standardstrack.com>) id 1U49KF-0005iy-NZ; Sat, 09 Feb 2013 04:14:35 -0800
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: I-D affects another or work in ietf groups
From: Eric Burger <eburger-l@standardstrack.com>
In-Reply-To: <8C48B86A895913448548E6D15DA7553B77476D@xmb-rcd-x09.cisco.com>
Date: Sat, 09 Feb 2013 07:14:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD3383F0-508F-4803-A0D1-5F14C6CDF64A@standardstrack.com>
References: <CADnDZ883hHwFw2-aPhzx-KaGCzyEuOhjNf1=58DtiBP8rw0Z5g@mail.gmail.com> <8C48B86A895913448548E6D15DA7553B77476D@xmb-rcd-x09.cisco.com>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Feb 2013 12:14:48 -0000

As well, if there is a conflict, it will certainly come out in IESG review or IETF Last Call.

On Feb 8, 2013, at 11:27 PM, Fred Baker (fred) <fred@cisco.com> wrote:

> Speaking for myself, I would say that an internet draft is relevant to work in a working group if and only if it is covered by the charter of the working group. Anyone can claim anything to dodge the requirement that they ask relevant groups to review it. That doesn't make the claim true.
> 
> In the event that you need a ruling, I would suggest discussing it with the relevant chairs and, if necessary, ADs. Generally speaking, they will have no axe to grind and can give you a reasonably objective answer.
> 
> On Feb 8, 2013, at 7:56 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
> 
>> Hi folks,
>> 
>> Related to one discussion with a participant about I-Ds affecting WGs,
>> I have a question after reading two real incidents. The following two
>> work process examples are to show the I-Ds/RFCs affects from
>> participants point of view;
>> 
>> 1) I got an understanding from one expert participant that his I-D is
>> not related to one RFC, even though it does involve similar objectives
>> and use-case, which was strange to me. So I understood from him that
>> his I-D is not affected by that RFC, even though his I-D does not
>> mention to exclude that RFC. IMO, I disagree with such producing I-D
>> by separate review-approach unaffected by other related RFCs (i.e. not
>> mentioned RFCs).
>> 
>> 2) While I was discussing within a WG about an I-D which is a second
>> version of one IETF prorocol, some participants thought that the I-D
>> obsolete the old version even if not mentioned in the I-D. It then was
>> requested to update and mention that it does not obsolete the older
>> version. New versions are related and can affect each other, or affect
>> people understanding, which requires more careful presentation for
>> such I-D.
>> 
>> I beleive that we have one source of producing RFCs, so all I-Ds and
>> RFCs are related some how, and they affect each other. So when I
>> review an item, I always like to consider all RFCs as much as I can to
>> make Internet better.
>> 
>> Is that approach right for review? please advise,
>> 
>> AB
>