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

Carlos Jesús Bernardos Cano <> Tue, 02 February 2016 13:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A778B1ACE1F for <>; Tue, 2 Feb 2016 05:46:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KtGua1wFzWca for <>; Tue, 2 Feb 2016 05:46:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BEB21B2AF1 for <>; Tue, 2 Feb 2016 05:46:23 -0800 (PST)
Received: by with SMTP id r129so118633958wmr.0 for <>; Tue, 02 Feb 2016 05:46:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 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 with ESMTPSA id e77sm16574039wma.18.2016. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Feb 2016 05:46:21 -0800 (PST)
Message-ID: <>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <>
To: Barry Leiba <>, The IESG <>
Date: Tue, 02 Feb 2016 14:46:20 +0100
In-Reply-To: <>
References: <>
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: <>
Subject: Re: [P2PSIP] Barry Leiba's No Objection on draft-ietf-p2psip-diagnostics-19: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?



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
> html
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> -------------------------------------------------------------------
> ---
> -------------------------------------------------------------------
> ---
> 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.