[mpls] Benoit Claise's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT)
"Benoit Claise" <bclaise@cisco.com> Thu, 07 January 2016 09:48 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAC81A8851; Thu, 7 Jan 2016 01:48:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160107094835.20273.74075.idtracker@ietfa.amsl.com>
Date: Thu, 07 Jan 2016 01:48:35 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/le5Ay-zmgYeT6VTbey9WU6vCupY>
Cc: mpls@ietf.org, evyncke@cisco.com, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org
Subject: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2016 09:48:35 -0000
Benoit Claise has entered the following ballot position for draft-ietf-mpls-rfc6374-udp-return-path-04: 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-mpls-rfc6374-udp-return-path/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- And we're now redoing the OWAMP/TWAMP protocols ... This is kind of sad that there is no alignment. At the very minimum, in the terminology and concepts. >From RFC 5357 +----------------+ +-------------------+ | Session-Sender |<-TWAMP-Test-->| Session-Reflector | +----------------+ +-------------------+ ^ ^ | | | | | | | +----------------+<----------------+ | | Server | | +----------------+ | ^ | | | TWAMP-Control | | v v +----------------+ | Control-Client | +----------------+ Something I already mentioned to the RFC 6374 authors in the past when doing my OPS-DIR review. Sigh... Anyway, please engage in the discussion regarding Eric Vyncke's OPS DIR review: This short I-D is quite clear and easy to understand, security & manageability sections are correct. I found nothing in this framework document which could cause operational issues EXCEPT: as I am unsure of the usual PLDM procedures, what is the expected behavior when a PLDM message (incl a URO) is received by a PLDM node which does not support this object type? If it is well defined in PLDM, then there is no problem of course. Can a reply be fragmented? Should the reply contains the DF bit for IPv4? Probably worth mentioning what to do over fragmentation. What is the expected behavior when the URO contains an IPv6 address and the PLDM responder only has IPv4 address(es)? Small nits: in introduction, I guess you meant "internally be forwarded" rather than "internally forwarded" Section 4.3, when selecting the source address, you may want to refer to RFC 6724
- [mpls] Benoit Claise's No Objection on draft-ietf… Benoit Claise
- Re: [mpls] Benoit Claise's No Objection on draft-… Stewart Bryant