Re: [Gen-art] Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21

Hitoshi Asaeda <asaeda@nict.go.jp> Fri, 24 November 2017 06:58 UTC

Return-Path: <asaeda@nict.go.jp>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3749129B15; Thu, 23 Nov 2017 22:58:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Cb2_0H756O9I; Thu, 23 Nov 2017 22:58:55 -0800 (PST)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49AA4129B11; Thu, 23 Nov 2017 22:58:55 -0800 (PST)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id vAO6wmX7070946; Fri, 24 Nov 2017 15:58:48 +0900 (JST)
Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw2.nict.go.jp with ESMTP id vAO6wmpC070938; Fri, 24 Nov 2017 15:58:48 +0900 (JST)
Received: from localhost (ssh1.nict.go.jp [133.243.3.49]) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTP id 03169EDDB; Fri, 24 Nov 2017 15:58:48 +0900 (JST)
Date: Fri, 24 Nov 2017 15:58:50 +0900
Message-Id: <20171124.155850.640089773115993135.asaeda@nict.go.jp>
To: meral.shirazipour@ericsson.com
Cc: draft-ietf-mboned-mtrace-v2.all@ietf.org, gen-art@ietf.org, mboned-chairs@tools.ietf.org
From: Hitoshi Asaeda <asaeda@nict.go.jp>
In-Reply-To: <ABCAA4EF18F17B4FB619EA93DEF7939A4F638E24@eusaamb104.ericsson.se>
References: <ABCAA4EF18F17B4FB619EA93DEF7939A4F638E24@eusaamb104.ericsson.se>
X-Mailer: Mew version 6.5 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at zenith2
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/psY7g8aDZ5bogGMHkHVRdBfl4Sc>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Nov 2017 06:58:58 -0000

Dear Meral Shirazipour,

Thank you for your careful review.
(And sorry for this late response.)

We've almost addressed your comments, and will submit the revision
whenever we, co-authors, agree on the changes.

Please see inline.

Subject: Gen-ART Last Call review of draft-ietf-mboned-mtrace-v2-21
Date: Fri, 17 Nov 2017 20:57:07 +0000

> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
> For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> 
> Document: draft-ietf-rtgwg-rlfa-node-protection-09
> Reviewer: Meral Shirazipour
> Review Date: 2017-11-16
> IETF LC End Date:  2017-11-23
> IESG Telechat date: NA
> 
> Summary:
> This draft is ready to be published as Standards Track RFC but I have comments.
> 
> Major issues:
> Minor issues:
> Nits/editorial comments:
> -please spell out acronyms at first use.

Thank you. Done.

> -[Page 7,8]
> "If an implementation receives an
>    unknown TLV type for the first TLV in a message, it SHOULD ignore and
>    silently discard the TLV and any subsequent TLVs in the packet
>    containing the TLV.  If an implementation receives an unknown TLV
>    type for a subsequent TLV within a message, it SHOULD ignore and
>    silently discard the TLV.  If the length of a TLV exceeds the
>    available space in the containing packet, the implementation MUST
>    ignore and silently discard the TLV and any remaining portion of the
> containing packet.  Any data in the packet after the specified TLV
>    length is considered to be outside the boundary of the TLV and MUST
>    be ignored during processing of the TLV.
> "
> 
> this whole paragraph is a bit confusing.
> 
> e.g. "If an implementation receives an unknown TLV type for the
> first TLV in a message", is this refering to the header TLV?

Yes. It is referring to the header. This is clarified in the proposed
re-wording as follows;

"If an implementation receives an unknown TLV type for the first TLV
in a message (i.e., the header TLV), it SHOULD ignore and silently
discard the entire packet."

> e.g. "If an implementation receives an unknown TLV type for a
> subsequent TLV within a message, it SHOULD ignore and silently
> discard the TLV.", does this mean TLVs after this one TLV should not
> be discarded?

For this statement, I'm asking to other co-authors to confirm the
meaning, because I (Hitoshi) think this wording gives a wrong
impression. We will clarify this statement in the revision ASAP.

> e.g. "Any data in the packet after the specified TLV length is
> considered to be outside the boundary of the TLV and MUST be ignored
> during processing of the TLV.", does this apply to last case only of
> when the length of a TLV exceeds the available space in the packet?

For that case (overflow bevond the packet boundary), there is no data
after the last specified TLV length. This sentence is not needed and
will be deleted.

> -[Page 12, 13], "UNIX timeval" or  timespec?
> (please verify if usec or nsec)

We'll say;

"The following formula converts from a timespec (fractional part in
nanoseconds) to a ..."

> -[Page 17], "An unique"--->"A unique"

Done. Thanks.

Best Regards,

Hitoshi


> Best Regards,
> Meral
> ---
> Meral Shirazipour
> Ericsson
> Research
> www.ericsson.com