Subject: Please check: Discussion transcript from SEND WG on Tuesday

From: Pekka Nikander <[email-masked]>
Date: Fri, 14 Nov 2003 10:30:20 -0600

Pasi, James, Greg, Margaret, Christian, Samita, Jari,
and Tony,

I have now prepared a transcript of the discussions that
took place at the SEND WG on Tuesday, based on minutes
provided by Greg Daley and Michael Richardsson.  Many
thanks to Greg and Michael!

Please check that what I have written matches accurately
enough with what you intended to say.  If not, please send
me corrections.

If you said something, and notice that we have missed
that, please let me know.

I will produce summarized minutes next week, and also post
a corrected version of this discussion.

[I am posting this from [email-masked], but please
  send replies to [email-masked].  The reason for
  posting from ericsson.com are the problems that I have
  with posting to the list.  I'm sorry for the inconvenience.]

--Pekka Nikander

Pasi Eronen: I reviewed the CGA draft and even checked the
  hashes in the examples, and the draft seems to be OK.

James Kempf: Thanks, these kinds of reviews are important,
  especially ones that go deep enough.

Greg Daley: Did Jon Wood implement the DCS/DCA response delay?  In
  other words, did the measured number include the DCS/DCA random delay?

James Kempf: No, I don't think so.  I will post a definite answer to
  the list.
  
Margaret Wasserman: Question.  HOW do we configure to use the secure
  address as the source address?  All the other address selection
  rules in RFC3484 check the prefix of the address.  How can the
  configuration table in RFC3484 dtermine if the address is a CGA
  address?  Or do we always want to prefer the secure address?

Christian Huitema: We already do this with RFC3014 privacy addresses.  
  We might not want to prefer a CGA address, we might want to use some
  other address, a throw away address which we use for privacy.
  We may also want to use a different key for privacy addresses.

Samita Chakrabarti: In terms of source addresses it is implementation
  specific how to determine whether to use a CGA address or not.  The
  local node will know if a given source address is a CGA or not.  The
  MIPv6 API contains switching of addresses on/off.

Jari: For care-of addresses, one might prefer, but why CGA?

Samita: I am not sure, I am probably not the best person to answer
  this question.  But please specify what the default mode is to be,
  to use CGA addresses or not?	For the question of whether a new API
  should be created or not, please consult the IPv6 WG.

Tony Hain: The new public keys will have to registered somewhere, right?

Jari Arkko: We do not need any infrastructure to store the keys.  

James: These keys aren't being used elsewhere. Only in RS/ND.

Tony Hain: If CGAs become the preferred addresses, we need to ensure
  that there is a place to make the keys available, since people will
  want to use the keys elsewhere.  So, don't go there right now.

James Kempf: We need to take this to the list.

Greg Daley:  I have not seen any hosts that send redirects.  However,
  if there indeed are such cases, maybe we have to have a look into
  this. 

James Kempf: Lets take this, too, to the list.

Pasi Eronen: I did the review of the NDopts document, too, and most of
  the issues are editorial in nature.  For example, the ndopts
  document says the modifier is 16 bits and the CGA document states
  that it is 16 octets (or was it the other way around?).  However, I
  have an issue with the timestamp algorithm.  I am not sure whether it
  works with 1 second resolution for timestamp, even with less than 1
  second timestamp.  Allow things to be off by 1 second. But I've sent
  this comment to the list already.  

  There seems to be also some text missing about unsolicited ND. If
  the node has some reason to update things, it can send them.

Jari Arkko: Yes, we need to handle these issues.  Thank you for
  bringing them up.

Pasi Eronen: There is also lots of redundant text. 

Jari Arkko: Yes, the document needs some serious editing.
  
James Kempf: The goal right now is to get the document ready, and
  announce another last call before the end of November, if possible.
  We will also send the document to the review board.  Apparently, it
  will take some time to process the review comments, but the goal is
  to get the document ready for IESG before the end of the year.
  Then it usually takes 6-9 months to get through the IESG and the
  RFC Editor.

Margaret Wasserman:  We need to try to do better than 9 years for
  getting this through.

James Kempf:  The idea is to shut down the working group of the IESG
  review, but keep the mailing list running anyway.

Margeret Wasserman: Maybe we need to keep the group on a hiatus if we
  need to go to draft standard.  But that is just a process issue.

James Kempf:  I like things to start, cruise, and reach end.  Hence I
  would prefer to close down the working group and run later another
  bof, if needed.