Re: [P2PSIP] Barry Leiba's No Objection on draft-ietf-p2psip-diagnostics-19: (with COMMENT)

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Tue, 02 February 2016 13:46 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A778B1ACE1F for <p2psip@ietfa.amsl.com>; Tue, 2 Feb 2016 05:46:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3] 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 KtGua1wFzWca for <p2psip@ietfa.amsl.com>; Tue, 2 Feb 2016 05:46:26 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 2BEB21B2AF1 for <p2psip@ietf.org>; Tue, 2 Feb 2016 05:46:23 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id r129so118633958wmr.0 for <p2psip@ietf.org>; Tue, 02 Feb 2016 05:46:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:content-type:mime-version:content-transfer-encoding; bh=S3sLdRxVk1+ZoOTi2JMu8+4RlwiQ/+2qJYVT+/g9IIc=; b=WaVA3MVvVdiHN6ihnjtVKv73rwESqPmvyIQC/f1kdTyqgL/9u5GperNIvTKqA8HjSp qpkTFKYWB3vZpPTrrhrC2Stz/qGKrWuoZYh+kmx5cMEi+HVS+Er7h320t95JwKHGP63P yznNlCmKbeMzMGKsYYdNG69NGxXljQwMWScgj+3GYc9Z8GiZHrbUpuoRuOq+t3ZmgkPP ptJyaCL7/C/cl5FkEC+fzDky0R+jxmgR8YnfjZFljtIdgoh5zMWfWQSVxhKwz4I6wC6O 6KqM9EuXK2qUPXPU69NwSVGiE9oRo+HeDCP3tvgc1DpGhtEDLMFNljgMPTGz63zu7K/Y SZJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:content-type:mime-version :content-transfer-encoding; bh=S3sLdRxVk1+ZoOTi2JMu8+4RlwiQ/+2qJYVT+/g9IIc=; b=YDp6Hoqg3SQvWzOtUz36Ygr3RO28iQAVxHzqFtCrMsGCweGI7iF9Dp6MXm7/IE7CBi ld17x113WjjEv8O+Vm4E/8ALAbPOxGdnGRLyywRYIxc3/IG0Yu46/KEgRTARH121/B2a B3i16UVpyoF/mbq7zZYdgMoq9BlUIGAI1hlLyJjuwLdwJTdGFnHtn+GOY5DVwy4T9WSi 59xwKQt0znt2aDrx/gWbnY5lWpzSVVYAJA3G6WlbusLsV/EIdicyZqJ88JGFvbrjyeh7 L/dgSlS2DfZyUhuUlC9IGZSrxRGMHivPLq1w1tPqHm7AzAy6kDyW9hjxB4NEz2PPU2Z/ WCTg==
X-Gm-Message-State: AG10YOReNfEfpgvjkDiU6iwGnC6CgBtWnue9M0xOPDz3oUXxKq0GVOvUbfoEwAF/Ry23cHOK
X-Received: by 10.28.96.198 with SMTP id u189mr16009088wmb.55.1454420782289; Tue, 02 Feb 2016 05:46:22 -0800 (PST)
Received: from ?IPv6:2001:720:410:1010:2247:47ff:fedb:3d7e? ([2001:720:410:1010:2247:47ff:fedb:3d7e]) by smtp.gmail.com with ESMTPSA id e77sm16574039wma.18.2016.02.02.05.46.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 05:46:21 -0800 (PST)
Message-ID: <1454420780.3763.9.camel@it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
Date: Tue, 02 Feb 2016 14:46:20 +0100
In-Reply-To: <20160129203946.14671.39449.idtracker@ietfa.amsl.com>
References: <20160129203946.14671.39449.idtracker@ietfa.amsl.com>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.18.3-1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/fPuN_joKv6RsS6Z_km-Hz3HDCV0>
Cc: p2psip-chairs@ietf.org, draft-ietf-p2psip-diagnostics@ietf.org, p2psip@ietf.org
Subject: Re: [P2PSIP] Barry Leiba's No Objection on draft-ietf-p2psip-diagnostics-19: (with COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2016 13:46:27 -0000

Hi Barry,

As document shepherd, I think I have to apologize because now that you
brought up the issue of "Updates RFC6940", I agree with you that there
is no reason for that. @Authors: can you remove that or comment why
this is required?

Thanks,

Carlos

On Fri, 2016-01-29 at 12:39 -0800, Barry Leiba wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-p2psip-diagnostics-19: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/
> 
> 
> 
> -------------------------------------------------------------------
> ---
> COMMENT:
> -------------------------------------------------------------------
> ---
> 
> For Sections 9.1 and 9.2, I wish there had been some working group
> discussion that resulted in the decision to make the registry
> policies
> Standards Action.  It seems that some softer policy, such as "IETF
> Review" (which might allow for registrations from Experimental
> documents)
> or Specification Required (which would allow review by a designated
> expert of a non-RFC specification) would work OK for this registry,
> and I
> would have liked the working group to have actively considered
> that.  But
> that ship has sailed for this document and this working group, and
> it's
> not likely to box us in for this case, so this is now a non-blocking
> comment.  Thanks for the discussion we've had on this point.
> 
> In addition to what Ben has already said...
> 
> One of the things that idnits calls out is this:
>   -- The draft header indicates that this document updates RFC6940,
> but
> the
>      abstract doesn't seem to mention this, which it should.
> 
> I believe it's not a problem that the abstract doesn't mention it,
> but
> one *reason* the abstract doesn't mention it is that the rest of the
> document doesn't mention it either.  It's not at all clear WHY this
> document updates 6940.  Why?  (This is in support of Ben's comment,
> as
> well as being a question to the shepherd.)
> 
> The idnits tool also mentions the pre-5378 disclaimer, and this has
> been
> resolved, so the disclaimer should be removed when the draft is
> updated.
> 
> I strongly agree with Ben's comment about needing explanations for a
> number of SHOULDs (and SHOULD NOTs) in the document.  RFC 2119 says
> that
> for SHOULD, "the full implications must be understood and carefully
> weighed before choosing a different course."  Without any
> explanation,
> there's no way for implementors to understand the implications and to
> weigh anything, and I tripped over that quite a number of times
> during my
> review.
> 
> I agree with Spencer's comment that we don't usually strong-arm IANA
> with
> 2119 key words.  It's a small point, and I don't think IANA are
> easily
> offended [ :-) ], but "IANA is asked to create" is a better approach
> than
> "IANA SHALL create", and so on.
> 
>