Opsdir last call review of draft-ietf-spring-oam-usecase-06
Joel Jaeggli <joelja@bogus.com> Fri, 30 June 2017 14:13 UTC
Return-Path: <joelja@bogus.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E837312EC23; Fri, 30 Jun 2017 07:13:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Jaeggli <joelja@bogus.com>
To: ops-dir@ietf.org
Cc: spring@ietf.org, ietf@ietf.org, draft-ietf-spring-oam-usecase.all@ietf.org
Subject: Opsdir last call review of draft-ietf-spring-oam-usecase-06
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149883201392.4666.499169365560986574@ietfa.amsl.com>
Date: Fri, 30 Jun 2017 07:13:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/heqYN1OiQgSsZ-heyGju2mbkveE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 30 Jun 2017 14:13:34 -0000
Reviewer: Joel Jaeggli Review result: Has Nits I have reviewed draft-ietf-spring-oam-usecase-06 as par of the OPS directorate review cycle forIETF last call. In general I think this document is ready to go however I have a couple of concerns that should probably at least be discussed prior to IESG review. >From my vantage point the document is not so much a description of a use case or requirements as it is the architectural wrapper around draft-ietf-mpls-spring-lsp-ping. It's most helpful in my opinion to review this one as though the other one was the companion document, from this vantage point I think the later document is effectively normatively referenced. Similarly the readiness of the later document (which is a bit earlier in it's lifecycle) raises the question of whether this one is ready to go. in the security considerations section the document notes: As mentioned in the introduction, a PMS monitoring packet should never leave the domain where it originated. It therefore should never use stale MPLS or IGP routing information. I think is is more accurate to say: Use of stale MPLS or IGP routing information could cause a PMS monitoring packet to leave the domain where it originated. PMS monitoring packets should not be sent using stale MPLS or IGP routing information. As it is necessary to know that the information is stale is order to follow the instruction, as is the case with for example convergence events that may be ongoing at the time of diagnostic measurement.
- Opsdir last call review of draft-ietf-spring-oam-… Joel Jaeggli
- Re: Opsdir last call review of draft-ietf-spring-… Carlos Pignataro (cpignata)