|
Unfortunately your mail did not answer my direct questions, which are
aimed at moving forward.
In terms
of your initative to look backward and dissect the minutes, perhaps you
should also take into consideration the progress of the draft. We
have:
IETF 72;
Introduces draft-lourdelet-radext-ipv6-dhcp-00 - Advice given for
doing a rfc3162bis
IETF
73;
Merged
rfc3162bis draft presented. Additionally remarks passed about the WG being
overloaded with drafts.
Preference expressed for non rfc3162bis approach
IETF74
states:
draft-lourdelet-radext-ipv6-access
introduced. (Just 3 attributes)
- Chair:
Document is currently in review for acceptance as a WG work item.
Only one review so far, which indicates that the document is not yet
ready. Please review the document and send comments to the
list!
- Problem
statement – RFC3162 needs additions to accommodate IPv6 production networks.
Feedback is coming in from actual deployments. Need
flexibility.
- IPv6 DNS
location needs to be configured on a subscriber basis – wholesale,
VPN.
- Implementation can happen in DHCP and
SLAAC.
- Review of
requirements – individual IPv6 addresses must be offered to the subscriber as
concatenation of prefix and interface id attributes does not cover all
cases.
- More
specific routes should be transmitted to the subscriber – multi-homing,
multiple attachments – see
draft-dec-dhcpv6-route-option-01.
- Prefix
lifetimes must be configured on a prefix basis.
- Glen Zorn:
New attributes should be added – No objection to do this from the WG.
The above feedback led to changes to
the draft, like introducing "lifetimes".
At this point however the draft seems
to have been OK'ed in principle by the WG, and there was no evidence of the
draft having "same negative feedback as had earlier
versions" ...
IETF75:
Discussion had, without
presenter, who happened to be there and reportedly did try to
present...
Redext virtual
meeting:
Discussion had, without any of the
authors. In the runup, emails asking for clarification went
unanswered.
Now, in terms of your note
below (I quote "we did have
attendance from people with a concrete interest in a subset of the
functionality"), it appears to be some kind of consensus call,
which is another rather unorthodox development given all of the
previous record.
-Woj.
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---
|