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(_at_)olddog(_dot_)co(_dot_)uk]
Sent: 24 February, 2014 1:55 PM
To: 'Roni Even';
draft-ietf-mpls-special-purpose-labels(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org
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