[OSPF] AD review of draft-ietf-ospf-rfc4970bis-02

Alia Atlas <akatlas@gmail.com> Tue, 22 September 2015 22:01 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C0C1A8EA9; Tue, 22 Sep 2015 15:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 hgqsaYGKXw4W; Tue, 22 Sep 2015 15:00:58 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 19FE71A8BC3; Tue, 22 Sep 2015 15:00:58 -0700 (PDT)
Received: by obbmp4 with SMTP id mp4so19399820obb.3; Tue, 22 Sep 2015 15:00:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gz7qycRCTqzcl1exkpKbrbHgud822aXk3wKyw6CRzF4=; b=vwsftVaV3xcJtOVaCfkZwFUT63sJHrUMVeUemOGcAPrRwXBNsTpsAykCgsqWpm8fDG VDP5jApTl0pnZ5I7ogdeIbJrVv0awDoPXqJo0D8HbHlQfr+Fe5eoSd064AcprCe98HMo inWm1Lfec4wOKbocltuSTjLPoQhkBOofv0M+cn/x6917UfufQ0uPaBP+iuCoQhUnPiT1 1pYsAuHprQZAv/VLqczVSJaEy5Qd6xl9uzh8JXyF2Xa5BJkcFW1MOB5aAeuLAnDGBSCL 4rg+R8H4OffhsQr0tY9pb8VSLCkBu8GddNUhIfdobpTQ5Tz2oXOU9swQ7FLJJy0zVNQp qlEQ==
MIME-Version: 1.0
X-Received: by 10.182.39.194 with SMTP id r2mr17600661obk.20.1442959257368; Tue, 22 Sep 2015 15:00:57 -0700 (PDT)
Received: by 10.60.55.170 with HTTP; Tue, 22 Sep 2015 15:00:57 -0700 (PDT)
Date: Tue, 22 Sep 2015 18:00:57 -0400
Message-ID: <CAG4d1rf+MsJXVy+G8W8vWjD=P_126cpjAFjr9e-+eCw=KLZzjQ@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: OSPF List <ospf@ietf.org>, draft-ietf-ospf-rfc4970bis@ietf.org
Content-Type: multipart/alternative; boundary=001a11c1d8d6f5ff4f05205d2199
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/SbGQYvxZ8XVLced6PvAfjaTqDBE>
Subject: [OSPF] AD review of draft-ietf-ospf-rfc4970bis-02
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2015 22:01:00 -0000

As is customary, I have done my AD review
of draft-ietf-ospf-rfc4970bis-02.  First, let me thank Acee for his work on
this draft.

I have two major concerns before asking for an IETF Last Call.  I would
like to have them
resolved by this Thursday so that the draft can make the Oct 15 IESG
telechat.

First, from a process concern, I do not see any active discussion on the
OSPF mailing list - even to simply say "yes - go forward".  I don't see
anything about this draft or discussion in minutes for IETF 92 or IETF 93.
  I'd prefer some indication besides silence and lack of opposition.  I do
realize that there are some process or protocol-tidying drafts where there
isn't
much interest.  However, I am particularly concerned because this is
changing RFC4970 is a way that should be backwards compatible but might
trigger issues.   I would encourage WG participants to PLEASE RESPOND!

Second, I can see the intent that by creating an Opaque ID and creating a
special meaning for 0, the draft is making efforts to preserve backwards
compatibility.  Please add a paragraph or subsection that articulates how
and why backwards compatibility isn't an issue.  For extra credit, what
happens if the same TLV information is advertised in multiple RI LSAs (as
part of moving it from one RI LSA to another)?

Are there any implementations of this draft?  Has backwards compatibility
been verified at all?

My minor issue is around the IANA considerations; I have detailed comments
below.

Here are additional comments.

1) In Sec 2: "The first Opaque ID, i.e., 0, should always contain the Router
   Informational Capabilities TLV and, if advertised, the Router
   Functional Capabilities TLV."  and Sec 2.2 "The first instance ID, i.e.,
0,
   should always contain the Router Informational Capabilities TLV and,
   if advertised, the Router Functional Capabilities TLV."

   Since I assume this is important for backwards compatibility, should
those
   be SHOULD instead of should?

2) In Sec 2.3: "The first defined TLV in the body of an RI LSA is the Router
   Informational Capabilities TLV."

   Surely that is only for the first Opaque ID=0?  Does each subsequent RI
LSA
   also need to contain a Router Informational Capabilities TLV??

3) In Sec 4 IANA Considerations:  This section is defining the different
IANA policies;
when RFC4970 was written, RFC5226 didn't exist.  But since you're doing a
bis,
perhaps you can align to the policies in RFC5226 and remove the unnecessary
text??

4) In Sec 4 IANA Considerations:  The registry for OSPFv3 LSA Function
Codes can
be found at
http://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-3
and what is in the draft doesn't match up.  I'd settle for defining the
ranges, and value 12 - but it's up to you and IANA on the preferences.
Would it make sense to change the policy from Standards Action to IETF
Review here also?

Same thing applies to the OSPF RI TLVS (
http://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-9
)   Also here, I think there
was agreement among the 4 of us who commented on the WG mailing list to
change this
from Standards Action to IETF Review.

5) In Sec 4 IANA Considerations: "All Router Functional Capability TLV
       additions are to be assigned through standards action."   Given the
discussion
about IETF Review vs. Standards Action for other registries, are you sure
you want
Standards Action?

I'm sure that we'll get this moving along quickly.

Thanks again!
Alia