I agree problem should be solved and given the size of the range not splitting it seems reasonable.
-Jon > On Sep 21, 2015, at 6:33 PM, Alia Atlas <[email protected]> wrote: > > Ok - so change the whole range from Unassigned (Standards Action) to > Unassigned (IETF Review)? > > Do others have opinions? > > Thanks, > Alia > >> On Mon, Sep 21, 2015 at 6:13 PM, Acee Lindem (acee) <[email protected]> wrote: >> Hi Alia, >> >> From: Alia Atlas <[email protected]> >> Date: Monday, September 21, 2015 at 5:59 PM >> To: Acee Lindem <[email protected]> >> Cc: "Alvaro Retana (aretana)" <[email protected]>, OSPF WG List >> <[email protected]>, "[email protected]" >> <[email protected]>, "[email protected]" >> <[email protected]> >> Subject: Re: [OSPF] IANA Considerations in draft-ietf-ospf-rfc4970bis >> >> Acee, >> >>> On Mon, Sep 21, 2015 at 5:57 PM, Acee Lindem (acee) <[email protected]> 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 <[email protected]> >>> Date: Monday, September 21, 2015 at 5:36 PM >>> To: "Alvaro Retana (aretana)" <[email protected]> >>> Cc: OSPF WG List <[email protected]>, "[email protected]" >>> <[email protected]>, "[email protected]" >>> <[email protected]> >>> 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) >>>> <[email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
