[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.
- [pim] Opsdir last call review of draft-ietf-pim-r… Susan Hares via Datatracker
- Re: [pim] Opsdir last call review of draft-ietf-p… Alvaro Retana
- Re: [pim] Opsdir last call review of draft-ietf-p… Susan Hares