Re: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis
"Acee Lindem (acee)" <acee@cisco.com> Mon, 21 September 2015 23:48 UTC
Return-Path: <acee@cisco.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 838A11A9147; Mon, 21 Sep 2015 16:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 OLU0zypAmVyk; Mon, 21 Sep 2015 16:48:04 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BE61A923E; Mon, 21 Sep 2015 16:48:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32283; q=dns/txt; s=iport; t=1442879284; x=1444088884; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C7y8IwhaxHnRaYjU+Rpj2YaevxjoEMuu60dfe500SMo=; b=kc334w6OptPKFeWP5pOgQmjBb6KnlbkRC1nqh/r0aOPsFN9ft00MPz27 RW7ymaxGyIYsonYMmvYbp3wVszjAAIaIjipvgd85eiTEP4Jwani1kW065 /xnqyVUrt6KysnYHSgqS6LOkaF1ALnd/Js3dQm/SFsT3/eZ3UU7z0Mpus E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAgAalgBW/5hdJa1dgldNVGkGvUYBDYFxAQmFeQIcgRs4FAEBAQEBAQGBCoQkAQEBBAEBASBIAwsQAgEIDgMDAQIhBwMCAgIfBgsUCQgCBA4FFIgFAxINty6PKQ2EZgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi3CCUIIsDQQHBoJjgUMFkjuDKQGLGIFugU2SDoNSg20fAQFChAFxiGiBBQEBAQ
X-IronPort-AV: E=Sophos; i="5.17,570,1437436800"; d="scan'208,217"; a="30787026"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 21 Sep 2015 23:48:03 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8LNm2fp014258 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2015 23:48:02 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Sep 2015 18:48:01 -0500
Received: from xhc-rcd-x02.cisco.com (173.37.183.76) by xch-aln-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 21 Sep 2015 18:48:01 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.127]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 18:48:01 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alia Atlas <akatlas@gmail.com>
Thread-Topic: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis
Thread-Index: AQHQ9LRhm+JodERs+k6Wx1tPPyBAAJ5H1ZoA///CrACAAEOegP//wOqAgABIjID//9HjAA==
Date: Mon, 21 Sep 2015 23:48:00 +0000
Message-ID: <D2260F5D.2F5BA%acee@cisco.com>
References: <D225EE98.D2A0B%aretana@cisco.com> <CAG4d1rdHd=raBDqBKtBNMp+-W6imTRaN76aSOZPKc_O3mJRk6A@mail.gmail.com> <D225F4AB.2F280%acee@cisco.com> <CAG4d1rfrBn0vBG=NJX5=OPaGSHD=cRyb5inKQe21ms4bVXpGuA@mail.gmail.com> <D225F80A.2F2E4%acee@cisco.com> <CAG4d1rfCUefp4oqXZ=zSeAenTtANMArCmOeOjTUOzuWcF=gZDQ@mail.gmail.com>
In-Reply-To: <CAG4d1rfCUefp4oqXZ=zSeAenTtANMArCmOeOjTUOzuWcF=gZDQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.36.7.24]
Content-Type: multipart/alternative; boundary="_000_D2260F5D2F5BAaceeciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/BiTSmbif5UR0l1PSQ3jfa99A6Mc>
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 23:48:09 -0000
From: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> Date: Monday, September 21, 2015 at 6:33 PM To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>> Cc: "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>>, OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "draft-ietf-ospf-rfc4970bis@ietf.org<mailto:draft-ietf-ospf-rfc4970bis@ietf.org>" <draft-ietf-ospf-rfc4970bis@ietf.org<mailto:draft-ietf-ospf-rfc4970bis@ietf.org>>, "ospf-chairs@ietf.org<mailto:ospf-chairs@ietf.org>" <ospf-chairs@ietf.org<mailto:ospf-chairs@ietf.org>> Subject: Re: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis Ok - so change the whole range from Unassigned (Standards Action) to Unassigned (IETF Review)? Exactly. Thanks, Acee Do others have opinions? Thanks, Alia On Mon, Sep 21, 2015 at 6:13 PM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote: Hi Alia, From: Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> Date: Monday, September 21, 2015 at 5:59 PM To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>> Cc: "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>>, OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "draft-ietf-ospf-rfc4970bis@ietf.org<mailto:draft-ietf-ospf-rfc4970bis@ietf.org>" <draft-ietf-ospf-rfc4970bis@ietf.org<mailto:draft-ietf-ospf-rfc4970bis@ietf.org>>, "ospf-chairs@ietf.org<mailto:ospf-chairs@ietf.org>" <ospf-chairs@ietf.org<mailto:ospf-chairs@ietf.org>> Subject: Re: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis Acee, On Mon, Sep 21, 2015 at 5:57 PM, Acee Lindem (acee) <acee@cisco.com<mailto: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 guess I’m not worried about the space being contiguous. Also, it seems the most common reason to obsolete an experimental draft is that it becomes accepted enough to be standards track. For everyone’s edification, here are the definitions from RFC 5226: IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored (or WG) documents with an IETF Last Call. Examples: IPSECKEY Algorithm Types [RFC4025], Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake Hello Extensions [RFC4366]. Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. Examples: BGP message types [RFC4271], Mobile Node Identifier option types [RFC4283], DCCP Packet Types [RFC4340]. Thanks, Acee 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<mailto:akatlas@gmail.com>> Date: Monday, September 21, 2015 at 5:36 PM To: "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>> Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "draft-ietf-ospf-rfc4970bis@ietf.org<mailto:draft-ietf-ospf-rfc4970bis@ietf.org>" <draft-ietf-ospf-rfc4970bis@ietf.org<mailto:draft-ietf-ospf-rfc4970bis@ietf.org>>, "ospf-chairs@ietf.org<mailto:ospf-chairs@ietf.org>" <ospf-chairs@ietf.org<mailto: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<mailto: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<mailto:OSPF@ietf.org> https://www.ietf.org/mailman/listinfo/ospf
- [OSPF] IANA Considerations in draft-ietf-ospf-rfc… Alvaro Retana (aretana)
- Re: [OSPF] IANA Considerations in draft-ietf-ospf… Alia Atlas
- Re: [OSPF] IANA Considerations in draft-ietf-ospf… Acee Lindem (acee)
- Re: [OSPF] IANA Considerations in draft-ietf-ospf… Alia Atlas
- Re: [OSPF] IANA Considerations in draft-ietf-ospf… Acee Lindem (acee)
- Re: [OSPF] IANA Considerations in draft-ietf-ospf… Alvaro Retana (aretana)
- Re: [OSPF] IANA Considerations in draft-ietf-ospf… Alia Atlas
- Re: [OSPF] IANA Considerations in draft-ietf-ospf… Acee Lindem (acee)
- Re: [OSPF] IANA Considerations in draft-ietf-ospf… Jon Mitchell