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

Alia Atlas <akatlas@gmail.com> Mon, 21 September 2015 21:59 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 AD0291A89B4; Mon, 21 Sep 2015 14:59:18 -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 ltb3T2m6UAaC; Mon, 21 Sep 2015 14:59:14 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 C402E1A89FD; Mon, 21 Sep 2015 14:59:09 -0700 (PDT)
Received: by oiww128 with SMTP id w128so66423033oiw.2; Mon, 21 Sep 2015 14:59:09 -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 :cc:content-type; bh=cop2gIu49sY2EmKr8qdRieJQfCMUhP/AqtefoH58lXo=; b=H7d4s9kcEvxo7TgNmTnFHCvdLGW+92XfF/bH1md0daxrkb/ntwg8Noart9vrgLIUaF p8H2lbfXMzhob9/v2KJkwSihMxjuJo/63Puj+yaFYd9MF80iqZYk77IPhOrJYX+jGYpH z46ULlHs8Ko9uaSr99nQE/gqzynpTO9hzwJWFq4caLkh9IaRvgDU2S6Zk4DPbNVYg1W3 cDJ/B6+J6G13Mo640jQOy3zR7o9/9Y+ZXRGaie4g3sL1vaOl6ixAG/glbwKVd5yhDEeP uRexNvTNXDpAJVrVoEaTmVxKGJJWjODYdEflzwUf1WVuIbgAnih4l8IBbmVf4NCqY3KT m8Tw==
MIME-Version: 1.0
X-Received: by 10.202.97.196 with SMTP id v187mr12615733oib.91.1442872749145; Mon, 21 Sep 2015 14:59:09 -0700 (PDT)
Received: by 10.60.55.170 with HTTP; Mon, 21 Sep 2015 14:59:09 -0700 (PDT)
In-Reply-To: <D225F4AB.2F280%acee@cisco.com>
References: <D225EE98.D2A0B%aretana@cisco.com> <CAG4d1rdHd=raBDqBKtBNMp+-W6imTRaN76aSOZPKc_O3mJRk6A@mail.gmail.com> <D225F4AB.2F280%acee@cisco.com>
Date: Mon, 21 Sep 2015 17:59:09 -0400
Message-ID: <CAG4d1rfrBn0vBG=NJX5=OPaGSHD=cRyb5inKQe21ms4bVXpGuA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Content-Type: multipart/alternative; boundary=001a113d3938ab4372052048fda6
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Ru5hF_rn7JlVDGCFfbY4PkFQbcE>
Cc: "draft-ietf-ospf-rfc4970bis@ietf.org" <draft-ietf-ospf-rfc4970bis@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis
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: Mon, 21 Sep 2015 21:59:18 -0000

Acee,

On Mon, Sep 21, 2015 at 5:57 PM, Acee Lindem (acee) <acee@cisco.com> wrote:

> Speaking as a WG member:
>
> Hi Alvaro, Alia,
>
> If we are going to change this, I would propose we change the allocation
> policy from “Standards Action” to “IETF Review”  as opposed to splitting
> the range.
>

That works for me, if you are ok having Experimental stuff mixed in with
Standards track.  The  former may become
obsoleted and leave gaps.

I'm happy to depend on your perspective and the WG to decide the best way
forward.

Regards,
Alia



> Thanks,
> Acee
>
> From: Alia Atlas <akatlas@gmail.com>
> Date: Monday, September 21, 2015 at 5:36 PM
> To: "Alvaro Retana (aretana)" <aretana@cisco.com>
> Cc: OSPF WG List <ospf@ietf.org>rg>, "draft-ietf-ospf-rfc4970bis@ietf.org" <
> draft-ietf-ospf-rfc4970bis@ietf.org>gt;, "ospf-chairs@ietf.org" <
> ospf-chairs@ietf.org>
> Subject: Re: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis
>
> Alvaro,
>
> 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.
>
> Regards,
> Alia
>
> On Mon, Sep 21, 2015 at 5:27 PM, Alvaro Retana (aretana) <
> aretana@cisco.com> wrote:
>
>> [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
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>>
>>
>