On Fri, Mar 13, 2009 at 01:09:59PM -0400, Ralph Droms wrote: > David - let me ask for specifics here. What sections would you drop from > the current draft, which would be replaced at a later date by additional > RFCs from v6ops? I don't think I would require the current draft to be changed materially. Section 4 contains no normative language, and is therefore largely informational. If it were mine, I would have focused more on an overview of how the information gets from the server to the client (ORO, placement of the option in the reply packet (root? IA?)), with an admission at the end of its intended use. So my ideal section 4 wouldn't refer to RFC 4861 at all; except that I understand its current use as a vehicle to explain the fields' contents and possible use to likely readers (the author's intended audience). To those ends, I think the authors should have freedom here. And of course, I think you need to move the RFC 4861 reference to an Informative References section, since I do not believe there has been any normative language referring to ND currently, and I would suggest against adding any. So long as we're talking about me; I have also been thinking that I would drop the router lifetime values, preferring instead for the fields contents to be "valid as long as the client holds its current lease (basically the longest valid lifetime of any addresses granted)", but I don't know if this interferes with some intention to support these options via Information-Request messages, so I have been witholding comment. I planned to wait and see the presentation before suggesting alterations. I do know that our software, as it operates at userspace and not in kernel space, does not seem to have reliable mechanisms to store router lifetimes to the kernel (depends on architecture, on some it is merely undocumented), and we probably would on some platforms tie the insertion and removal of any routes to IP address lifetimes instead until such time as kernel keepers make this configuration possible. I would prefer not to have to add extra complexity to track the router lifetime separately, at any rate. The idea is that this follows the same way we use or invalidate other configuration state in the lease - such as nameservers or domain search. They are valid until the last address expires, and they are updated (old-removed, new-inserted) upon every Renew or Rebind. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgpb2zIq5i1DG.pgp
Description: PGP signature