[RTG-DIR] RtgDir review: draft-ietf-sidrops-ov-clarify-03

Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 10 August 2018 13:21 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B63C130DC8; Fri, 10 Aug 2018 06:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 KrjgfrGLSsk8; Fri, 10 Aug 2018 06:21:07 -0700 (PDT)
Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB9112F18C; Fri, 10 Aug 2018 06:21:07 -0700 (PDT)
Received: by mail-pf1-x443.google.com with SMTP id a26-v6so4537606pfo.4; Fri, 10 Aug 2018 06:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=U4F1tIhDiRvaOBANXGNlZCBnZC2NqNEhPPVLTj65RHg=; b=H/p8c2Gyucbh7V/DOeG2IepO4Q6sUp1K4ixFtl9czmjWglBGn+G6aQwPn3AEUTIgJs WmLnSKI0w8f2zY/5gwA//OUMvAsNOdgaDkSuQXizzPIb650U4WHqv9yTXnGfgbpQeXCE sh/p1SN2UONZlRk14WuCORuvXgbsVQGuhdX+6aypLjTVvAgkjfPN1gNfsWNyny+kLIJd snfGv3s2zWVRKY9pniVoT8TE8UaxXzHOTNnQv03HpVZ+eXkGnu2NWZ1k4xk2cNy22HNQ Eeqd1yupHvxvRDBM8u3IBEmLE0nUYyDJNxjsS1uKy4afcGz9v8PaHxqfva/w1FsHduUa 8Qpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=U4F1tIhDiRvaOBANXGNlZCBnZC2NqNEhPPVLTj65RHg=; b=qIJt4gXvcWla0yL+r/g7Witxz5wn9EiUxv8idbpLOlbtsFR7XOZgmbGE95Ic5coASf U6+51O2broO7SNrIX+++sX9+pLj4zrIcpeZl3K76UBCrMbi477oSd+LbJ1uwA7E9wQRL T6gr42ZWS1nZ2yth4DygxdV80ZturrV8EHLzBG/aP+RRFPmNt3tD1B8bBvrvpAEnWcq9 2nMFN8PvjzBlgqS5qABgGYqahs/EnMZJJCPRlxbeW1GSQhxkOAnOy3ZeTUA0d4aDA9E9 Nu0cpiHcDzs59t/cepF83iJoRY0ycNdENWDAB0v8whb7PVTfCnVWfFOPvByhCbI1lkHq Yv1A==
X-Gm-Message-State: AOUpUlHJzymHtGvyqpJUyVhdNg7j41oAAXJVhyrYXCIVolpBevOFiTQu DVTXnpi6NtivnEQIGR73aG8=
X-Google-Smtp-Source: AA+uWPzOM5exQxxljBUlu+NauC7vX90HFs0QfIJBqD0v7H2YP1uyHPe/aRpicFv2auHYBPLFx1X3dw==
X-Received: by 2002:a62:1089:: with SMTP id 9-v6mr6956756pfq.30.1533907266493; Fri, 10 Aug 2018 06:21:06 -0700 (PDT)
Received: from [192.168.0.109] ([122.167.129.176]) by smtp.gmail.com with ESMTPSA id b18-v6sm12610634pgk.15.2018.08.10.06.21.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Aug 2018 06:21:05 -0700 (PDT)
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org, draft-ietf-sidrops-ov-clarify.all@ietf.org, sidrops@ietf.org, "dhruv.dhody@huawei.com" <dhruv.dhody@huawei.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Message-ID: <72ee1d70-d135-a445-75df-65df06fda61a@gmail.com>
Date: Fri, 10 Aug 2018 18:51:02 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ncFk30b8ADJE6l4NsaBO1uZL9pk>
Subject: [RTG-DIR] RtgDir review: draft-ietf-sidrops-ov-clarify-03
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2018 13:21:14 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The
Routing Directorate seeks to review all routing or routing-related 
drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the 
Routing ADs.
For more information about the Routing Directorate, please see ​
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion 
or by
updating the draft.

Document: draft-ietf-sidrops-ov-clarify-03
Reviewer: Dhruv Dhody
Review Date: 10 Aug 2018
IETF LC End Date: Unknown
Intended Status: Standards Track

Summary:

     I have some minor concerns about this document that I think should be
     resolved before publication.

Comments:

     This is a standards track draft that clarifies the behavior of Origin
     Validation in BGP (and thus updates RFC 6811). It states that the 
origin
     validation MUST be done for all routes, including the imported 
routes; where
     as the RFC 6811 uses "SHOULD". This I-D further states that the 
policy is
     applied only if explicitly configured by the operator. The 
clarifications
     are clear and easy to follow. The I-D is technically sound and 
almost ready.

Major Issues:

     No major issues found.

Minor Issues:

     - The text in RFC6811 uses the term “lookup” and “validation 
state”, the
       clarification uses the term “mark”. This might be a bit pedantic but
       wouldn’t it be better to state the clarification in terms of RFC6811?

     - Since RFC4271 and RFC6480 are stated as mandatory reading to 
understand
       this I-D in section 2, shouldn’t they be normative references?

     - I agree with the Gen-ART review, that ask for BGP in the title, 
in fact
     “Prefix Origin Validation” in the title would be better!

Nits:

     - Expand RPKI in Abstract.

     - The Requirement language phrasing is little different from RFC 8174.

Thanks!
Dhruv