Hi Adrian, I do not have a strong position on this topic ( I can agree that deprecating a code point is a rare case) , I was wondering why the difference and I can agree with any direction that you will choose about the maturity level needed Roni > -----Original Message----- > From: Adrian Farrel [mailto:adrian@xxxxxxxxxxxx] > Sent: 24 February, 2014 1:55 PM > To: 'Roni Even'; draft-ietf-mpls-special-purpose-labels.all@xxxxxxxxxxxxxx > Cc: ietf@xxxxxxxx; gen-art@xxxxxxxx > Subject: RE: Gen-ART LC review of draft-ietf-mpls-special-purpose-labels-05 > > Hi Roni, > > Thanks for taking the time. > > > Minor issues: > > 1. In section 3.2 (a): I noticed that the policy to update the > > registry > according > > to section 5 is standard action so it should be the same here since > >this is > an > > update to the registry. > > Hmmm, but I don't think so. > Section 5 (and the existing registry) define the procedures to be used for > assigning new values from a namespace per 5226. Procedures for > retiring/deprecating values are rarely, if ever, documented and do not need to > follow the same rules as are used for assignments. > > That said, I think I can see some value in symmetry. but it seems a bit OTT to > have a Standards Track RFC saying "this code point is not used". What is certain > (and we appear to agree on this) is that IETF consensus is needed (presumably > as tested by IETF last call on the relevant I-D). > > Since we disagree, but my disagreement is not too strong, I will be guided by > the IESG (and specifically our sponsoring AD) as to whether to change: > OLD > An RFC with at > least Informational status is required. > NEW > A Standards > Track RFC is required. > END > > > Nits/editorial comments: > > 1. In section 3 last sentence “This answer to this” should be “The ..” > > Ack > > > 2. In section 3.2 item c you have “for for” > > Ack > > Cheers, > Adrian