Obsoleting the IPv6 Endpoint Identifier (EID) Option

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

(Wesley Eddy) Discuss

Discuss (2012-11-08 for -01)
Please stick to the marking of this option as historic, and remove all mention of potential filtering based on the presence of this option. The current document incorrectly conflates the two matters in both the abstract and security considerations.  There is no security issue identified with this option, it is merely unused in the current Internet.

I also believe the document should clearly say that nothing has been found WRONG with the option in a technical sense that would drive this deprecation; it is just simply attempting to clarify that this entry does not have the same relevance as others.

(Sean Turner) Discuss

Discuss (2012-11-13 for -01)
This is a discuss-discuss:

If assignments for this registry are "IESG Approval, IETF Consensus or Standards Action processes" couldn't we equally as well have obsoleted it with a management item and saved some cycles?  The management item could have been it's unused let's deprecate it.

I had to chuckle that we're obsoleting an option that was defined without a draft with a draft.
Comment (2012-11-13 for -01)
No email
send info
I support Wes' discuss.

(Ron Bonica) Yes

(Benoît Claise) Yes

Comment (2012-11-14)
No email
send info
Note: I read version 2 of the draft.
This document cleans up an entry in the registry that points nowhere: [draft-gont-intarea-obsolete-eid-option]
So I'm in favor of that. 
Now, if there is a way to make that change without a document, even better...

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2012-11-14)
No email
send info
Can we please just make this happen with a
management item?

I'd also be quite happy, as Brian suggests,
to leave it alone.  Although I suppose we
can undeprecate it in the future with an
IESG action, as well.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

(Russ Housley) No Objection

Barry Leiba No Objection

Comment (2012-11-01 for -01)
No email
send info
Please respond to IANA's questions in their "[IANA #615807] Last Call" note.
If you no longer have the note, you can find it in the document history in the datatracker:

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

Comment (2012-11-14)
No email
send info
I agree with Wes' discuss and the text in question should be removed. 

The 'intarea' part in the file name is not right, as this wasn't discussed there. 
So, where else was this document discussed? 
I would expect this information in the document write-up, but this information isn't there.

(Brian Haberman) Abstain

Comment (2012-11-13 for -01)
No email
send info
1. If this document goes forward, I agree with Wes' DISCUSS points.

2. I am abstaining because I think this is a completely unnecessary action to take.  I completely agree with the following statement from Brian Carpenter:

"I'm not sure we should do this. The base format defined by draft-ietf-nimrod-eid-00 is generic, with only an initial variant
defined for Nimrod, so it could be used for pretty much any future type of EID. I see no harm in leaving the option defined
but sleeping."

Ignas Bagdonas No Record

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Benjamin Kaduk No Record

Suresh Krishnan No Record

Warren Kumari No Record

Mirja Kühlewind No Record

Alexey Melnikov No Record

Alvaro Retana No Record

Adam Roach No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record