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

Alia Atlas <akatlas@gmail.com> Tue, 22 September 2015 22:11 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 D12E61A907D; Tue, 22 Sep 2015 15:11:01 -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 8eikTtIX1n0e; Tue, 22 Sep 2015 15:10:59 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 EF6E01A906D; Tue, 22 Sep 2015 15:10:58 -0700 (PDT)
Received: by oiev17 with SMTP id v17so14016700oie.1; Tue, 22 Sep 2015 15:10:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4rf7PgqhYUQCe2NnJbRO9I2wobwJxpBkiIr7E5frGV0=; b=AfhgLqQAFv38D3xTLieDTHI+38I7YtB6eTLUJGnSyshxhA8ErDIXZqVMoQ8e68lSiL mSD9+dQVHrVLOEj9MlDxW3E4rI4jYV4wpHWx0YoYpksWtM7h8OK17aFpwcIWTKoBaVKZ eXMeqvgM/efW71yh+19fHuWwDh4o4N7X5AYAofQLT0oRHZGrO2oTTz9/RNNUOtlM/GIK +liT8HxeUk5biLQ3vKN/jkZDRlxoph4BalkLEP+ohpwWZOl7Dh3IF3UBa6QuPXRwcGpr wrS37/8QWCbPQfDQska2l1HD7oKD/bsi6UzNGFq4WOtWD/cb0liJima9Lod4ItOMAES3 wZGA==
MIME-Version: 1.0
X-Received: by 10.202.198.139 with SMTP id w133mr16273202oif.72.1442959858384; Tue, 22 Sep 2015 15:10:58 -0700 (PDT)
Received: by 10.60.55.170 with HTTP; Tue, 22 Sep 2015 15:10:58 -0700 (PDT)
In-Reply-To: <CAG4d1rf+MsJXVy+G8W8vWjD=P_126cpjAFjr9e-+eCw=KLZzjQ@mail.gmail.com>
References: <CAG4d1rf+MsJXVy+G8W8vWjD=P_126cpjAFjr9e-+eCw=KLZzjQ@mail.gmail.com>
Date: Tue, 22 Sep 2015 18:10:58 -0400
Message-ID: <CAG4d1rdxgbao277AuGTjHpwdAZcnu5s9hZu212xuOF+5FxbUyA@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=001a1134fbd6c8c6c505205d450e
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/ujjFCe5qMZPUkpobi4aJgzkewc4>
Subject: Re: [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:11:02 -0000

Minor correction:

On Tue, Sep 22, 2015 at 6:00 PM, Alia Atlas <akatlas@gmail.com> wrote:

> 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!
>

In IETF 91 minutes, I see a presentation and question from Shraddha about
making it MT capable.  There was no
answer except take it to the list and no follow-up discussion.

Am I missing anything?

Regards,
Alia



> 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
>