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) <aret...@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 > >
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
