Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Loa Andersson <loa@pi.nu> Mon, 20 January 2020 07:55 UTC

Return-Path: <loa@pi.nu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB671200B5; Sun, 19 Jan 2020 23:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 d-G2QT7CLYJQ; Sun, 19 Jan 2020 23:55:28 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80A5120025; Sun, 19 Jan 2020 23:55:27 -0800 (PST)
Received: from [192.168.1.6] (unknown [119.94.173.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1300C3640D1; Mon, 20 Jan 2020 08:55:23 +0100 (CET)
Subject: Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
To: Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, SPRING WG <spring@ietf.org>
Cc: 6man Chairs <6man-chairs@ietf.org>
References: <ECC21DA8-0156-41D2-921E-177389D3C904@employees.org>
From: Loa Andersson <loa@pi.nu>
Message-ID: <09adcd59-13ae-448b-6a48-5e7471dbd121@pi.nu>
Date: Mon, 20 Jan 2020 15:54:41 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <ECC21DA8-0156-41D2-921E-177389D3C904@employees.org>
Content-Type: multipart/mixed; boundary="------------1148490B59AD80A1FA80BE02"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9fTiZEEzMbwD8bDx2pAQgB4iGbI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2020 07:55:34 -0000

WG,

I have reviewed the entire document.

First, I'm not an IPv6 expert.

As far as I can see the sued on

I have not used github, I had a couple of attempts to learn the tools,
but so far I have failed.

I have instead done what I use to do, use the review tool with Word.

Since I sometimes have a pushback on the docx-format I save the result
as a .txt-file. Drawback is that all comment show up as refrences to a
list at the end of the document. But you can't get everything.


/Loa

PS gives this output for this draft; it is quite a lot and in itself are
so much that it is worth sending it bck to the authors and asking them
to fix it. Was the noits tool checked at all before starting the wglc?

idnits 2.16.02

/tmp/draft-ietf-6man-spring-srv6-oam-03.txt:

   Checking boilerplate required by RFC 5378 and the IETF Trust (see
   https://trustee.ietf.org/license-info):
 
----------------------------------------------------------------------------

      No issues found here.

   Checking nits according to 
https://www.ietf.org/id-info/1id-guidelines.txt:
 
----------------------------------------------------------------------------

      No issues found here.

   Checking nits according to https://www.ietf.org/id-info/checklist :
 
----------------------------------------------------------------------------

   ** There are 3 instances of too long lines in the document, the 
longest one
      being 6 characters in excess of 72.

   == There are 5 instances of lines with non-RFC3849-compliant IPv6 
addresses
      in the document.  If these are example addresses, they should be 
changed.


   Miscellaneous warnings:
 
----------------------------------------------------------------------------

   == The copyright year in the IETF Trust and authors Copyright Line 
does not
      match the current year

   -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
      defined in RFC 2119.  If it is intended as a requirements 
expression, it
      should be rewritten using one of the combinations defined in RFC 2119;
      otherwise it should not be all-uppercase.

   == The expression 'MAY NOT', while looking like RFC 2119 requirements 
text,
      is not defined in RFC 2119, and should not be used.  Consider 
using 'MUST
      NOT' instead (if that is what you mean).

      Found 'MAY NOT' in this paragraph:

      To perform ICMPv6 ping to a target SID an echo request message is
      generated by the initiator with the END.OP or END.OTP SID in the
      segment-list of the SRH immediately preceding the target SID. 
There MAY
      or MAY NOT be additional segments preceding the END.OP/ END.OTP SID.

   == The expression 'MAY NOT', while looking like RFC 2119 requirements 
text,
      is not defined in RFC 2119, and should not be used.  Consider 
using 'MUST
      NOT' instead (if that is what you mean).

      Found 'MAY NOT' in this paragraph:

      To traceroute a target SID a probe message is generated by the
      initiator with the END.OP or END.OTP SID in the segment-list of 
the SRH
      immediately preceding the target SID.  There MAY or MAY NOT be 
additional
      segments preceding the END.OP/ END.OTP SID.

   -- The document date (December 18, 2019) is 32 days in the past.  Is this
      intentional?


   Checking references for intended status: Proposed Standard
 
----------------------------------------------------------------------------

      (See RFCs 3967 and 4897 for information about using normative 
references
      to lower-maturity documents in RFCs)

   == Missing Reference: 'SL' is mentioned on line 190, but not defined

   -- Looks like a reference, but probably isn't: '2' on line 191

   -- Looks like a reference, but probably isn't: '1' on line 191

   -- Looks like a reference, but probably isn't: '0' on line 192

   == Missing Reference: 'RFC7011' is mentioned on line 230, but not defined

   == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is mentioned on line
      241, but not defined

   == Missing Reference: 'RFC792' is mentioned on line 701, but not defined

   == Missing Reference: 'RFC 8403' is mentioned on line 660, but not 
defined

   == Unused Reference: 'RFC0792' is defined on line 823, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC8403' is defined on line 843, but no explicit
      reference was found in the text

   == Outdated reference: A later version (-08) exists of
      draft-ietf-spring-srv6-network-programming-06


      Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 5 comments 
(--).

      Run idnits with the --verbose option for more detailed information 
about
      the items above.

On 05/12/2019 04:53, Ole Troan wrote:
> Hello,
> 
>    As agreed in the working group session in Singapore, this message starts a new two week 6MAN Working Group Last Call on advancing:
> 
>    Title    : Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
>    Author   : Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen
>    Filename : draft-ietf-6man-spring-srv6-oam-02
>    Pages    : 23
>    Date     : 2019-11-20
>                           
>      https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
> 
> as a Proposed Standard.
> 
> Substantive comments and statements of support for publishing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the author. This last call will end on the 18th of December 2019.
> 
> To improve document quality and ensure that bugs are caught as early as possible, we would require at least
> two reviewers to do a complete review of the document.  Please let the chairs know if you are willing to be a reviewer.
> 
> The last call will be forwarded to the spring working group, with discussion directed to the ipv6 list.
> 
> Thanks,
> Bob & Ole, 6man co-chairs
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64