Re: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis

Alia Atlas <> Mon, 21 September 2015 21:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 655F51AC3BF; Mon, 21 Sep 2015 14:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.999
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9YFFwurOmzKX; Mon, 21 Sep 2015 14:36:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D98F1AC3B9; Mon, 21 Sep 2015 14:36:39 -0700 (PDT)
Received: by obbda8 with SMTP id da8so93391732obb.1; Mon, 21 Sep 2015 14:36:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oIdCW5shtNefnS0Qb95yFDHiJDaHe4eAdlmI6FwLQcY=; b=i25UtTgqQYnzUzzWz7j7G8GPLqFRG1PwFA8ivLrHtHXArWW+jxK92OUebBO+UHCU6r nZEKHQ7XP4Oqk/Nn3zU9hbUbSbpv+58ga0eTWkF9rkLyGt9tt/YTb5dF0KpGyftvaZyA HziLgP1Nxq0GcCPil0sGqnuCDXq7DUwt4P/8sLVt0NVtyHw4tmimrysuaYQqAnfirPrt izJekEOq790gkEv3hdctRI4V3vyvm4xgaFK1O4aH/VmW6HRdwLpRG3/S+UDnWq94wrHd 1jMwVRirpgAgZ8fz1kPKHkgBkZ6xeQk2K+NwC1E/jQIqKdSF42rjLzk6O9fDtjF6s7aM RB+A==
MIME-Version: 1.0
X-Received: by with SMTP id l8mr13813293oem.61.1442871398970; Mon, 21 Sep 2015 14:36:38 -0700 (PDT)
Received: by with HTTP; Mon, 21 Sep 2015 14:36:38 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 21 Sep 2015 17:36:38 -0400
Message-ID: <>
From: Alia Atlas <>
To: "Alvaro Retana (aretana)" <>
Content-Type: multipart/alternative; boundary=089e0149ce38313bf4052048adf2
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Sep 2015 21:36:46 -0000


Is there a reason not to split up the Unassigned range into Standards
Action and RFC Required?
Also, are you picking RFC Required over IETF Review [RFC5226]?  The former
would open up
for Independent Stream RFCs while the latter would not.

Can we get opinions from the WG?  I am expecting to do my AD review of this
draft and get it
moving - hopefully for the Oct 15 telechat - assuming the document is in
the fine shape that I
expect from the OSPF WG.


On Mon, Sep 21, 2015 at 5:27 PM, Alvaro Retana (aretana) <>

> [WG Participant Hat On]
> Hi!
> I know that the WG has asked for publication
> of draft-ietf-ospf-rfc4970bis, but I would like to see a change in the IANA
> Considerations Section before moving forward.   Sorry for being so late..
> The ID (and rfc4970) define a registry for OSPF RI TLVs.  Currently, the
> only way to get a value assigned is through Standards Action (which
> requires a Standards Track RFC).  There is a range reserved for
> Experimentation — I understand why these values are not to be assigned
> (rfc3692).
> However, there is work that could that could benefit from a less strict
> assignment policy, where the code may be in general deployment, and even
> enabled by default in products — not what rfc3692 had in mind.  In this
> case I am specifically referring to the TTZ work — now that it is on the
> Experimental track, it doesn’t meet the requirement for Standards Action
> and given the size of potential deployments I don’t think it’s practical to
> just pick a value off the range reserved for Experimentation.  I am sure
> that, if not right now, other work will also benefit from a less strict
> policy.
> Proposal:  redefine the Reserved space so that half of it remains Reserved
> (the top half) while the other half uses a different assignment policy.
>  I’m proposing RFC Required (rfc5226) as the assignment policy.
> The text in 4970bis already talks about a Standards Track RFC being able
> to change the assignment policy for the Reserved space — as long as we’re
> doing the bis work, we might as well include this change.
> Given that the ID is already with the AD, I could make the same comment
> when the IETF Last Call is issued, but I think we may need WG consensus on
> changing the registry — so it might be easier to take care of it now.
> Thanks!
> Alvaro.
> _______________________________________________
> OSPF mailing list