[MBONED] Alia Atlas' No Record on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)
Alia Atlas <akatlas@gmail.com> Tue, 23 January 2018 22:09 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: mboned@ietf.org
Delivered-To: mboned@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 958FF12D850; Tue, 23 Jan 2018 14:09:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alia Atlas <akatlas@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mboned-mtrace-v2@ietf.org, Leonard Giuliano <lenny@juniper.net>, mboned-chairs@ietf.org, lenny@juniper.net, mboned@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151674537456.15690.10597962809822974600.idtracker@ietfa.amsl.com>
Date: Tue, 23 Jan 2018 14:09:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/D62Aq3CH_l_jP9Vja-PS65eqtpE>
Subject: [MBONED] Alia Atlas' No Record on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2018 22:09:35 -0000
Alia Atlas has entered the following ballot position for draft-ietf-mboned-mtrace-v2-22: No Record 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-mboned-mtrace-v2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) In Sec 3, the first paragraph says: "If an implementation receives an unknown TLV type for a subsequent TLV within a message, it SHOULD ignore and silently discard the entire packet." This appears to me to remove the possibility of incremental deployment of new features or TLVs. A rationale for why future-proofing isn't needed would be helpful. I do see the Augmented Response Block and Augmented Query Block have sub-types, which does help with extensibility. 2)End of Sec 3: "Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed. For example, if an Mtrace2 Query or Request message arrives in as an IPv4 packet, all addresses specified in the Mtrace2 messages MUST be IPv4 as well. Same rule applies to IPv6 Mtrace2 messages." I do not understand the rationale for forbidding some addresses being IPv4 and some IPv6. Presumably, some could even be unnumbered interfaces. Many networks are dual-stack or may have IPv4 in one part of the network and IPv6 in another part. What is the reason for ruling this out as a valid situation? I do see that the encodings are problematic if partly IPv4 and partly IPv6 - but I do not see a reason that IPv4 addresses could not be sent as mapped into IPv6. 3) Sec 3.2.1: "If the actual number of hops is not known, an Mtrace2 client could send an initial Query message with a large # Hops (e.g., 0xffffffff), in order to try to trace the full path." Since the #Hops field is an octet long - the largest value should be 255; specifying for a uint32 instead of a uint8 is incorrect. 4) Sec 3.2.1: If all the addresses in the Query message must be either IPv4 or all must be IPv6, the way of determining which it is from the length should be clearly specified. I.e. The length field MUST be either 8 plus 3*4 (IPv4 addresses) or 8 + 3*16 (IPv6 addresses); if the length is 20, then IPv4 addresses MUST be assumed and if the length is 56, then IPv6 addresses MUST be assumed. One could - of course, simply force all IPv6 addresses since an IPv4 address can be represented as an IPv6 address. That would allow any of these addresses to be either IPv4 or IPv6 while formatted as IPv6. 5) Sec 3.2.2: "The format of an Mtrace2 Request message is similar to an Mtrace2 Query except the Type field is 0x02." This should be clearer and more normative. The Mtrace2 Request TLV is exactly the same as an Mtrace2 Query except for the identifying Type field of 0x02. The same applies to 3.2.3 for Mtrace2 Reply.