Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)

["Brian Haberman" <[e-mail]>]

Brian Haberman has entered the following ballot position for
draft-ietf-6man-stable-privacy-addresses-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am taking the somewhat curious route of raising a DISCUSS on a document
that I am shepherding.  I will return to a Yes when these issues are
resolved.  Thomas Narten raised a good point that this document does not
mention the work published in RFCs 4436 and 6059 (from the concluded DNA
WG).  Two of the points he raised are worth addressing in this document
prior to publication.

1. If you have stable storage (and many devices do), it makes sense to
just cache the addresses instead of
regenerating them. DNA does this. Seems like that option should be
allowed. (the current document suggests saving the number of DAD
iterations in stable storage... why do that if you can just save the
address itself?)

2. DNA also has recommendations for detecting when you (re)connect to a
network you visited before. That is pretty much the same thing this spec
needs to do in order to generate the same addresses when connecting to a
previously visited network (i.e., the Network_ID paramater). For the
wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal
address pair of routers to identify a link. This document might suggest
doing the same thing.