[pim] Opsdir last call review of draft-ietf-pim-reserved-bits-03

Susan Hares via Datatracker <noreply@ietf.org> Fri, 13 September 2019 16:08 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pim@ietf.org
Delivered-To: pim@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4804E12009C; Fri, 13 Sep 2019 09:08:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Susan Hares via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: ietf@ietf.org, pim@ietf.org, draft-ietf-pim-reserved-bits.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.101.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Susan Hares <shares@ndzh.com>
Message-ID: <156839092320.32031.10069621346683776171@ietfa.amsl.com>
Date: Fri, 13 Sep 2019 09:08:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/hAR3qLV7hViQ7c1zQifMctY3Tts>
Subject: [pim] Opsdir last call review of draft-ietf-pim-reserved-bits-03
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 16:08:43 -0000

Reviewer: Susan Hares
Review result: Has Issues

OPS-DIR review

General comment: This is needed specification for PIM and clearly written.

Issue: Issue/Error in document 
However, this document does not specify the error handling if a PIM implementation does 
not abid by the MUSTs in section 4 defined as follows:  

   Unless otherwise specified, all the Flag Bits for each PIM type are
   Reserved [RFC8126].  They MUST be set to zero on transmission, and
   they MUST be ignored upon receipt.  The specification of a new PIM
   type, MUST indicate whether the bits should be treated differently.

This issues becomes a serious issue if it negates any error handling or changes
any existing error handling. 

I suspect this is not really a serious issue, but a flaw in the write-up. 
I suspect that because you set to zero on transmission, and 
ignored on receipt you will not engage in any error handling. 

However, it is necessary to state that so that machines testing 
the PIM and SM-PIM protocols will easily add this to their testing suite. 

2) Issue:  Security considerations in general are the same as 
[RFC7761] and {RFC3973], but bogus error handling (depending how you do #1) 
may impact the security considerations. 

3)  Minor Issue:  Should Section 3 include a change to RFC3973 - section 4.7.1 

Editorial Issues: 
It really help the reader trying to piece together the specifications to provide 
an example reference point. 

Since I looked each of these up: 

Section 3:  page 3, paragraph 1, RFC7761 - section 4.9 
Section 4:  page 3, paragraph 2.   RFC8126 - section 6 
Section 4.1: page 4, section 4.1, RFC5059, - section 5
Section 4.2: page 4, Section 4.2, RFC5015, - section 3.7.21
Section 4.3: page 4, section 5.3  RFC8364 - section 3.1

It would be helpful to the reader to provide sections numbers for the 
references.   If you would select other ref erences, it is further proof
that it would be useful to indicate which sections you are referring to.