[Int-area] [IANA #992480] FW: New Version Notification for draft-ietf-intarea-probe-08.txt

"Amanda Baber via RT" <iana-issues-comment@iana.org> Tue, 12 December 2017 21:36 UTC

Return-Path: <iana-shared@icann.org>
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 CD52C12956D; Tue, 12 Dec 2017 13:36:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.978
X-Spam-Level:
X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3MC19edfD7yj; Tue, 12 Dec 2017 13:36:05 -0800 (PST)
Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902A912956B; Tue, 12 Dec 2017 13:36:05 -0800 (PST)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id A5A1CE0CE8; Tue, 12 Dec 2017 21:36:04 +0000 (UTC)
Received: by request3.lax.icann.org (Postfix, from userid 48) id 6BED5C20667; Tue, 12 Dec 2017 21:36:04 +0000 (UTC)
RT-Owner: Nobody
From: Amanda Baber via RT <iana-issues-comment@iana.org>
Reply-To: iana-issues-comment@iana.org
In-Reply-To: <BLUPR0501MB20510DB6091365C2F508C04DAE340@BLUPR0501MB2051.namprd05.prod.outlook.com>
References: <RT-Ticket-992480@icann.org> <151311235688.14136.16514177051945871238.idtracker@ietfa.amsl.com> <BLUPR0501MB20510DB6091365C2F508C04DAE340@BLUPR0501MB2051.namprd05.prod.outlook.com>
Message-ID: <rt-4.2.9-7308-1513114564-421.992480-9-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #992480
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
CC: draft-ietf-intarea-probe.all@ietf.org, stefan.winter@restena.lu, jeanmichel.combes@gmail.com, yaronf.ietf@gmail.com, stewart.bryant@gmail.com, int-area@ietf.org, rbonica@juniper.net, michelle.cotton@iana.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Tue, 12 Dec 2017 21:36:04 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/I6JNdkY54QaVw5qESXHEWbxf4wo>
Subject: [Int-area] [IANA #992480] FW: New Version Notification for draft-ietf-intarea-probe-08.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 12 Dec 2017 21:36:09 -0000

Hi Ron,

We need to ask for one more thing that we didn't ask for in our review, and it's because there's an error in the registration procedure data in the registries. Both https://www.iana.org/assignments/icmpv6-parameters and https://www.iana.org/assignments/icmp-parameters incorrectly state that the IESG Approval or Standards Action are the registration procedures for all "Code" registries. 

However, RFC 4443 and RFC 2780 state that "The policy for assigning Code values for new IPv6 ICMP Types not defined in this document should be defined in the document defining the new Type" (https://tools.ietf.org/html/rfc4443#section-6.1) and "The policy for assigning Code values for new IPv4 ICMP Types should be defined in the document defining the new Type value" (https://tools.ietf.org/html/rfc2780, section 6). 

Can you provide registration procedures for all of the Code registries? For our purposes, these could be added to the document as late as after IESG approval, when we're completing the actions, if that's more convenient/appropriate. 

Was our identification of 15 as the maximum values for the Code registries correct?

Amanda

On Tue Dec 12 21:14:40 2017, rbonica@juniper.net wrote:
> Folks,
> 
> I have posted a new version of draft-ietf-intarea-probe reflecting
> IETF LC comments from Joel, Stewart, Stephan, Yaron and Amanda. Please
> take a look at the document to make sure that I have addressed your
> comments satisfactorily.
> 
> Ron
> 
> 
> -----Original Message-----
>  From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Tuesday, December 12, 2017 3:59 PM
> To: Ron Bonica <rbonica@juniper.net>; Mohamed Boucadair
> <mohamed.boucadair@orange.com>; Jen Linkova <furry@google.com>; Reji
> Thomas <rejithomas@juniper.net>; J. Linkova <furry@google.com>; Chris
> Lenart <chris.lenart@verizon.com>
> Subject: New Version Notification for draft-ietf-intarea-probe-08.txt
> 
> 
> A new version of I-D, draft-ietf-intarea-probe-08.txt has been
> successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:           draft-ietf-intarea-probe
> Revision:       08
> Title:          PROBE: A Utility For Probing Interfaces
> Document date:  2017-12-12
> Group:          intarea
> Pages:          17
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-probe/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-intarea-probe-08
> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-probe-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-probe-08
> 
> Abstract:
>    This document describes a network diagnostic tool called PROBE.
>    PROBE is similar to PING, in that it can be used to query the
> status
>    of a probed interface.  It differs from PING in that it does not
>    require bidirectional connectivity between the probing and probed
>    interfaces.  Instead, PROBE requires bidirectional connectivity
>    between the probing interface and a proxy interface.  The proxy
>    interface can reside on the same node as the probed interface or it
>    can reside on a node to which the probed interface is directly
>    connected.  This document updates RFC 4884.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
>