|
In looking through the WG minutes, I do not see much support for the assertions you make below. The minutes of IETF 73 in Minneapolis (see http://www.ietf.org/proceedings/73/minutes/radext.txt) indicate that the WG gave significant negative feedback on both drafts presented. The "next steps" were for the drafts to incorporate WG feedback and address the concerns. The idea of a merger was brought up (not by me), but was not indicated in the next steps for advancement. The minutes of IETF 74 shows that the presenter did not show up (see http://www.ietf.org/proceedings/74/minutes/radext.htm). The minutes of IETF 75 (see http://www.ietf.org/proceedings/75/minutes/radext.txt) disclose that the the document http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access was presented, and garnered some of the same negative feedback as had earlier versions. While the authors did not attend the virtual interim, we did have attendance from people with a concrete interest in a subset of the functionality. It was David Miles who made the suggestion for the WG to consider http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 as the way forward, and who also proposed addressing the feedback that had been obtained from the WG at IETF 73 and 75. Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 16:23:07 +0200 From: wdec@cisco.com To: bernard_aboba@hotmail.com; radiusext@ops.ietf.org Bernard,
with reference to the minutes below, I would like to post some observations and ask for clarifications:
Draft-lourdelet-radext-ipv6-access-01 was the result of merging at least two drafts that had IPv6 as a common theme. This merger was done based on suggestion by the WG as well as your opinion (IETF74) that the WG was overloaded with drafts. Below you appear to steer towards a path that to go back to two drafts since in a single draft some of the proposals would definitely be lost.
Now, it's rather unfortunate that at neither IETF 75 nor at the interim meeting below the authors of draft-lourdelet-radext-ipv6-access-01 were heard but that the discussion on the draft happened anyway with conclusions reached. This seems a rather unorthodox way to proceed and has likely been the cause of even more confusion.
We're currently planning on a two draft approach, pretty much reverting to the state prior to the "merged draft", along with changes to rid of any datatype issues (fingers crossed) and additional explanatory text. Before we proceed on this path, which to some may seem to be yet another goose chase, could you confirm that this is also your expectation?
In addition to the above, at various points it has been claimed that a) there is "little interest" in the WG in this work and/or b) that outstanding comments have not been addressed.
Regarding the "lack of interest", this also seems to be a rather odd claim given the array of authors on the drafts, the people offering to review and those having direct discussions on the WG mailer. Are you now convinced of "interest"?
In terms of "outstanding comments", with the exception of the datatype debacle, it would be appreciated if you could point to ones that were not addressed.
Thanks,
Woj.
---snip---
IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest, then there was a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways to address the review from Alan. The document utilizes a tagging scheme similar to, but not exactly the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been progressing (and is now expired). Bernard: It seems like many of the attributes that are tagged relate to a router advertisement, correct? Hannes: That is my understanding. Bernard: One of the objections to the current scheme is that it creates multiple new tagged data types. A new attribute is needed for each element of the RA that needs to be expressed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (or the entire) RA. David Nelson: It seems like the lack of progress on Extended Attributes is creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic use. But it doesn't make a recommendation. If we don't get Extended Attributes done, then we will be creating a problem. After finishing Design Guidelines, it seems like this needs to be our #2 priority. ---snip--- |