[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

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>
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)

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