|
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--- |