Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05

Barry Leiba <barryleiba@computer.org> Tue, 16 April 2013 19:07 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DD221F976A for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 12:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.851
X-Spam-Level:
X-Spam-Status: No, score=-102.851 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm3wpFEvDlDs for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 12:07:25 -0700 (PDT)
Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE721F9771 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 12:07:25 -0700 (PDT)
Received: by mail-ve0-f172.google.com with SMTP id db10so753595veb.17 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 12:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0HzfbEpEt+4SfO0vwMUG/gGYn2sODDGaOyoHa6y7AVs=; b=XtUzsS6nao4Jgkdo1Znv7BecjLeqW2yDdT8HAqxMm4QeOOdpe5xypgxrnmJGZ9/swW r2V0UBs0rkdVPKp6dbO/U45nXFJNEpXxfbqsxFcajkx82xfCtOR0/EIDGRcNjhatIcSV QEQnzFu8VCrN4lXirdyONTnvT1/q2crgcWaImt/3ZfXo5b4v0BUnOtFfpkUZiBpT5QCV SQZJDSmL8PHyiNvmaZVgXposWo2U3kQoBxSpm9+olgDmbt3zhQTwJ50KrQ7Qs4yJPLtX jhCCz316buoaW0+XFVJEEuTOT4S9n4cki1D8XGnKhxJreHGJ54LXVbBdeH39mcPMGW1H PXyA==
MIME-Version: 1.0
X-Received: by 10.220.99.75 with SMTP id t11mr2514730vcn.72.1366139244545; Tue, 16 Apr 2013 12:07:24 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Tue, 16 Apr 2013 12:07:24 -0700 (PDT)
In-Reply-To: <516D6EF1.90001@gmail.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com> <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com> <516CF39D.7020306@gmail.com> <CAC4RtVB_BN3oYwpWBW6pGHXK_OvbP2588AnpxEU_L+RV5jE9ng@mail.gmail.com> <516D4583.7020707@gmail.com> <CA+9kkMA2FDH3DSLED33uS5R0VSxyUok96OEU9=LtODu+nYRv3A@mail.gmail.com> <516D6EF1.90001@gmail.com>
Date: Tue, 16 Apr 2013 15:07:24 -0400
X-Google-Sender-Auth: b-6jLh0m-XbQ7F5kk4Euwn5Asi4
Message-ID: <CAC4RtVB3x3A3oPWwHjdqX1MscxPHmDnC0fyFutra1wGQkmLtCQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=089e015373f4628be404da7f1412
Cc: "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "Liubing \(Leo\)" <leo.liubing@huawei.com>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 19:07:26 -0000

> it's just that doing a second downref Last Call for this document seems a
bit OTT.

Actually, as this doc is itself Informational, there are no downrefs.  We
can change any reference to normative, with no need for a second last call.
 That would only be needed if this doc were Standards Track or BCP.

Barry

On Tuesday, April 16, 2013, Brian E Carpenter wrote:

> Ted,
>
> On 16/04/2013 16:06, Ted Hardie wrote:
> > On Tue, Apr 16, 2013 at 5:35 AM, Brian E Carpenter <
> > brian.e.carpenter@gmail.com <javascript:;>> wrote:
> >
> >> Yes, I am aware of that, and it's a matter of judgement, but
> >> since this draft is not in any sense a protocol specification
> >> or a pseudo-BCP, I am not sure why it needs *any* normative
> >> references, let alone downrefs. There is certainly no
> >> process requirement for them.
> >>
> >>
> > I certainly agree that there is no process requirement, but there is a
> > potentially useful result.  When I see a document like this with 9
> > normative references (as it has now), I get the sense that those are the
> > ones which are needed context and that the informative ones are useful
> > additional information.  That maps to "Essential reading" and "Useful
> > additional information", which is pretty much the same mapping as
> > "Normative" and "Informative" have in a protocol spec.  It's not
> *exactly*
> > the same, I grant you, but it's an approximation.  My question about the
> > three listed as "starts from" might have been better phrased as:  are
> these
> > "Essential Reading" or "Useful additional information"?
>
> IMHO, the RFCs are necessary reading for a complete understanding.
> The I-D is far too expired for that, although there has been some
> discussion of reviving its contents.
>
> Of course, as an author I will follow whatever the WG chairs and AD
> decide is the consensus - it's just that doing a second downref Last Call
> for this document seems a bit OTT.
>
>     Brian
> >
> > regards,
> >
> > Ted Hardie
> >
> >
> >>    Brian
> >>
> >>> Barry
> >>>
> >>> On Tuesday, April 16, 2013, Brian E Carpenter wrote:
> >>>
> >>>>>>> "starts from existing work in [RFC5887],
> >>>>>>> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the
> >>>> references
> >>>>>>> to these documents are informative.  If the document is meant to be
> >> an
> >>>> extension,
> >>>>>>> rather than a replacement, such that these documents must be read
> to
> >>>> get the full
> >>>>>>> picture, than a normative reference may be better.
> >>>>>> Well, we don't have a category for "informative, but really
> important
> >>>> context", so I leave it to you to pick.  I would personally likely
> >> choose
> >>>> normative to highlight their importance.
> >>>>> [Bing2] Ok, if normative could highlight the importance without
> >>>> implication of extension or replacement, then I think it is good.
> Thanks
> >>>> for the suggestion.
> >>>>
> >>>> RFC 5887 and 4192 are Informational so cannot be normative, and the
> >> draft
> >>>> is long-expired so cannot be normative.
> >>>>
> >>>> Regards
> >>>>    Brian
> >>>> _______________________________________________
> >>>> apps-discuss mailing list
> >>>> apps-discuss@ietf.org <javascript:;> <javascript:;>
> >>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org <javascript:;>
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/apps-discuss
>