Subject: Draft RADEXT Virtual Interim Minutes

From: Bernard Aboba <[email-masked]>
Date: Tue, 13 Oct 2009 12:34:57 -0700

Here is a draft of the RADEXT WG Virtual Interim Minutes. 

Please take a look at these minutes and add/edit/correct as necessary. 

===============================================
Minutes of the RADEXT WG Virtual Interim
October 13, 2009

Design Guidelines

Alan:  -09 has been submitted.  This includes a number of clarifications
with respect to tags, VSA formats, simple versus complex types.  
There are no MUSTs or MUST NOTs in the document.  Guidelines try to
encourage good practice, but should not be followed slavishly. 

Dan: Jari has cleared his discuss.  So the document could be sent to the
RFC Editor for publication immediately.  

Bernard:  Not clear that the document is ready. 
There are still two open issues from IETF last call: Issues 313 and 314. 

Issue 313 concerns the "security exemption".  Does this apply to any attribute
relating to security or authentication?  There was confusion on this point
during the review of the PKMv1 document. 

For user authentication or RADIUS security attributes there is computation 
involved:  the client has to compute something and the server has to verify,
or vice-versa.  If an attribute relates to security (e.g. sending a certificate) 
but there is no computation, does the exemption still apply?
In that case, it might have been possible to use the String
type, but a complex attribute would require new code on both the client and server. 

Issue 314 was filed by Hannes.  It was to be followed by specific text to address the
concerns, but this wasn't provided.

Hannes:  The state of the art has advanced.  In some designs addition of code is
no longer a big issue, scripts can be plugged in.  Also, parsers have improved,
and could enable complex attributes to be supported automatically. 
So are we locking ourselves into the past? 

David Nelson:  Many RADIUS server implementations utilize a data dictionary.  This
allows administrators to add the definition of a new attribute without having to
upgrade the server.  If an attribute doesn't have to require a server upgrade, that
is probably a good thing.  

Bernard:  There are a lot of legacy RADIUS servers out there that implement
the data dictionary  model described in RFC 2865.  For those implementations,
the data dictionary provides benefits.  It can save administrators time
and money, allowing them to support a new attribute immediately without waiting for
a RADIUS server upgrade. 

David Nelson:  It is also possible to use opaque attributes, where the data
is not parsed by RADIUS but by some other component.  Those attributes
are sent to and from a plugin.  

Dan Romascanu:  There is also the question of whether normative language is being used
in the same way as described in RFC 2119.  

Do we need to update the draft? 

Bernard Aboba:  How about an RFC Editor note? 
Dan:  That would be easier. 

David Nelson:  I think it would be best to get the document published and then see how
well it works in the real world.

Bernard:  So far, we've used it in reviewing two documents, the PKMv1 document, and the
IPv6 access document.  In both cases, there was confusion about how the guidelines applied
that required clarifications in the text.  So the "real world" experience is not so good. 
That's why the document has taken so long to finish. 
 
Bernard: Alan -- can you take the action item to work with Dan on addressing the RFC 2119 issue
as well as proposing an RFC Editor note to address issue 313? 

Status Server

Alan:  This draft was revised.  An applicability subsection was added.  There were some
terminology changes.  

David Nelson:  Does this document just describe what has been deployed, or does it also
describe how Status-Server is used in RADSEC?

Alan:  It is focused on what has been implemented.  The RADSEC document uses Status-Server
as an RFC 3539 Watchdog, but that is covered in the RADSEC document. 

Bernard: Status-Server was originally implemented by Ascend in their concentrators. 

Alan:  It was subsequently implemented in RADIATOR and FreeRADIUS.  

Bernard:  It would be good if we could get some additional reviewers to look at whether
the document accurately describes their implementations.  This isn't a standards-track
document; its job is just to describe what has been implemented.   Do we have any
volunteers:

David Nelson:  I will take a look at it. 

RADIUS over TCP

Alan:  We added text to the applicability section.  We're now using the term "RADIUS over TLS" instead
of a vendor's product name (RADSEC). We also added text on the head-of-line blocking issue.  
Bernard:  As I recall, Magnus (Transport AD) raised this issue initially. What can be done to address this 
issue other than opening multiple TCP connections?
Alan:  Nothing.
Dan:  What is the issue specifically?
Alan:  If a packet is lost, then all traffic that was intended to travel on the TCP connection has to
wait until the data at the head-of-the-line is acknowledged.  This isn't an issue with UDP. 
Hannes:  One of the reasons we created the SCTP transport for Diameter was to address the head-of-line
blocking issue.  But SCTP has not been widely implemented.
Alan: For those that are interested, FreeRADIUS now supports RADIUS over TCP, so you can play with it.
Bernard: Does the latest revision address Issues 315 and 316?
Alan:  Yes.
Bernard: OK.  If there are no open issues, then we could do another WG last call.

RADIUS over DTLS

Alan:  RDTLS has been implemented in Stefan's RADSEC Proxy.  I am implementing it as well. 
This draft was not revised. 
David Nelson: Isn't this draft expired?  What is the status?
Alan:  It is not expired.  
Bernard:  We issued a call for interest.  Only one or two people responded.  There are no
open issues at the moment.  We need more reviews.

IEEE 802 Attributes

Dan Romascanu:  Is this document only about WLAN attributes or wired IEEE 802 attributes as well?  Are
the attributes usable on multiple technologies? 
Bernard: A number of the attributes are specific to a technology.  For example, there are attributes
that relate to IEEE 802.11r specifically.  There are also attributes that relate to IEEE 802.1X-REV. 
Joe Salowey:  IEEE 802.1X-REV does apply to wireless, but there are aspects (such as announcements)
that were only meant to be implemented on wired networks.  
Bernard:  At one point we had attributes specific to IEEE 802.11s, but the security model changed, so
we removed them.  
David Nelson:  What is the status of the document?
Bernard Aboba:  IEEE 802.1X-REV has completed Sponsor Ballot.  We were waiting until the resolution of
Sponsor Ballot comments to align the document with IEEE 802.1X-REV. 
Joe Salowey: IEEE 802.1X-REV is now going into recirculation ballot.  So it is a good time to look at
it again. 
Bernard Aboba:  The document is referenced in Appendix E of IEEE 802.1X-REV.  But it is not a normative
dependency. 
Joe Salowey:  Now that IEEE 802.1X-REV has settled down, I will review the document again, to see what
changes may be needed. 
Bernard Aboba:  After Joe is done with his review, what are the next steps?  
Dan Romascanu:  For a standards track document, it can either be a WG work item, or an AD sponsored
document.  I would prefer a WG work item.
Bernard:  There was a call for interest in November 2007, but it never completed.  So the document has
been in limbo for almost two years now. 
David Nelson: Did anyone respond to the call?
Bernard Aboba:  Some people responded, yes. 
David Nelson:  I was waiting for IEEE 802.1 to send their requirements. 
Bernard Aboba:  IEEE 802.1 provided their review of -08 in July 2008.  That is now up on the liaison archive.
David Nelson: We can either send the document to the RFC Editor or run a quick WG last call on it, once
it is aligned with IEEE 802.1X-REV. 

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. 

Bernard:  Agreed.  To be clear though, this document does not currently depend on Extended Attributes. 
Question:  If Extended Attributes were further along, would this document use it? 

David Miles:  I don't think so.  

David Nelson:  It seems like there are a number of use cases here, and they are not clearly described. 
Bernard:  Previous documents have had very well defined uses cases.  RFC 3162 supports address auto-
configuration.  RFC 4818 supports DHCPv6 Prefix Delegation.  This document supports multiple modes,
and that is confusing. 

David Miles:  In looking at the attribute list, there are a set of attributes relating to router advertisements
that require tagging, but another set of attributes like IPv6-Address and IPv6-DNS-Server-Address that do not. 
Would it make sense to split the document into two parts, one focusing on DHCPv6, and
the other one on router advertisements? 

Bernard Aboba: Yes, I think this would help.

David Nelson:  Which attributes are you interested in?

David Miles: For the Broadband Forum, IPv6-Address is of the most immediate interest.  IPv6-DNS-Server-Address 
is relevant but isn't as important since in most cases name resolution is being handled over IPv4. 

Bernard Aboba:  If that is what you need, then focusing on that would enable things to go forward much more
quickly.  Can you put a document together that focuses on that? 

David Miles:  There is already a document that does that. 

David Nelson:  Which one? 

David Miles:  http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00

Bernard Aboba:  Yes, that document just handles the attributes you are interested in.  However, it confused
the WG because it only talked about DHCPv6 and RADIUS, but did not talk about authentication.  RADIUS is
spoken between a RADIUS client and server.  So if the RADIUS client is also a DHCPv6 server, then it makes
sense.  But if the DHCPv6 server is separate, then it's not clear how it works.  Does the NAS pass the
RADIUS attributes to the DHCPv6 server, and if so, how?  Is there authentication going on between the
DHCPv6 server and the RADIUS server?  If there are no authentication attributes is this a Call Check,
or is it changing the RADIUS protocol in some way?  

David Miles:  I can include material on the Broadband Forum scenarios.  If I work with Benoit to create
an -01 with that additional material would that help?

Bernard Aboba:  Yes, it would help a great deal. 

Summary/Wrapup

Bernard:  At the last virtual interim, the feedback on DimDim was not very positive.  So we tried LiveMeeting this time.  How did it work for people? 
Dan Romascanu: The conference bridge was fine. 
Alan DeKok:  I could not use the web conferencing software, it was only available on Windows. 
Dan Romascanu:  It required me to install additional software (Outlook addin).  That is a big deal. 
Bernard Aboba:  DimDim also required a software install.  Though it supported more platforms. 
David Nelson:  Having a teleconference bridge, Jabber and slides is fine. 
David Miles:  As long as the slides don't get too long  or there are too many people in the meeting.  Otherwise it's easy to lose your place. 
Bernard Aboba:  They had a session on WebEx at IETF 75, in the Working Group Chairs meeting.  I asked the Secretariat if we could get access, but didn't get a response.  So it was
either DimDim or LiveMeeting. 
Dan Romascanu:  I will inquire about the availability of WebEx. 

Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not currently scheduled to meet at IETF 76.  We have just completed the Virtual Interim, and 
IETF 76 is in just a few weeks. 
Dan Romascanu:  Who is attending?
David Nelson:  I will not attend. 
Bernard: No
Alan DeKok: No
Hannes: Yes
Dan Romascanu:  There are disadvantages to not holding a meeting at IETF 76.  You will miss the opportunity to interact with the community, particularly participants from Asia.  
It would be good to have a representative at IETF 76.  Hannes is very busy, but perhaps you can find someone to represent RADEXT. 
Bernard:  If there is WebEx available, we could participate remotely. 
Dan Romascanu:  I will look into supporting WebEx at the OPS Area Meeting.  There are cost concerns.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 13 Oct 2009 15:57:20 -0400

On Oct 13, 2009, at 3:34 PM, Bernard Aboba wrote:

> <snip>

In clarification, I will review the document for clarity and  
coherency, but I'm not an expert on what exactly was implemented in  
terms of the Status-Server feature, so I won't be able to comment on  
the accuracy with which the draft reflects deployments.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 13 Oct 2009 16:18:38 -0700

David Nelson said:

"In clarification, I will review the document for clarity and coherency, but
I'm not an expert on what exactly was implemented in terms of the
Status-Server feature, so I won't be able to comment on the accuracy with
which the draft reflects deployments."

Right.  I will clarify the minutes to that effect.  Ideally we would like
some implementers as reviewers to address the accuracy issue.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 14 Oct 2009 13:01:57 +0700

I don't see a list of attendees.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Wednesday, October 14, 2009 2:35 AM
To: [email-masked]
Subject: Draft RADEXT Virtual Interim Minutes

Design Guidelines

Issue 313 concerns the "security exemption".  Does this apply to any
attribute
relating to security or authentication?  There was confusion on this point
during the review of the PKMv1 document. 

For user authentication or RADIUS security attributes there is computation 
involved:  the client has to compute something and the server has to verify,
or vice-versa.  If an attribute relates to security (e.g. sending a
certificate) 
but there is no computation, does the exemption still apply?
In that case, it might have been possible to use the String
type, but a complex attribute would require new code on both the client and
server. 

Issue 314 was filed by Hannes.  It was to be followed by specific text to
address the
concerns, but this wasn't provided.

Hannes:  The state of the art has advanced.  In some designs addition of
code is
no longer a big issue, scripts can be plugged in.  Also, parsers have
improved,
and could enable complex attributes to be supported automatically. 
So are we locking ourselves into the past? 

David Nelson:  Many RADIUS server implementations utilize a data dictionary.
This
allows administrators to add the definition of a new attribute without
having to
upgrade the server.  If an attribute doesn't have to require a server
upgrade, that
is probably a good thing.  

Bernard:  There are a lot of legacy RADIUS servers out there that implement
the data dictionary  model described in RFC 2865.  For those
implementations,
the data dictionary provides benefits.  It can save administrators time
and money, allowing them to support a new attribute immediately without
waiting for
a RADIUS server upgrade. 

Dan Romascanu:  There is also the question of whether normative language is
being used
in the same way as described in RFC 2119.  

David Nelson:  I think it would be best to get the document published and
then see how
well it works in the real world.

Bernard:  So far, we've used it in reviewing two documents, the PKMv1
document, and the
IPv6 access document.  In both cases, there was confusion about how the
guidelines applied
that required clarifications in the text.  So the "real world" experience is
not so good. 
That's why the document has taken so long to finish. 
 
Bernard: Alan -- can you take the action item to work with Dan on addressing
the RFC 2119 issue
as well as proposing an RFC Editor note to address issue 313? 

Status Server

Alan:  This draft was revised.  An applicability subsection was added.
There were some
terminology changes.  

David Nelson:  Does this document just describe what has been deployed, or
does it also
describe how Status-Server is used in RADSEC?

Alan:  It is focused on what has been implemented.  The RADSEC document uses
Status-Server
as an RFC 3539 Watchdog, but that is covered in the RADSEC document. 

Bernard: Status-Server was originally implemented by Ascend in their
concentrators. 

Bernard:  It would be good if we could get some additional reviewers to look
at whether
the document accurately describes their implementations.  This isn't a
standards-track
document; its job is just to describe what has been implemented.   Do we
have any
volunteers:

RADIUS over TCP

Alan:  We added text to the applicability section.  We're now using the term
"RADIUS over TLS" instead
of a vendor's product name (RADSEC). We also added text on the head-of-line
blocking issue.  
Bernard:  As I recall, Magnus (Transport AD) raised this issue initially.
What can be done to address this 
issue other than opening multiple TCP connections?
Alan:  Nothing.
Dan:  What is the issue specifically?
Alan:  If a packet is lost, then all traffic that was intended to travel on
the TCP connection has to
wait until the data at the head-of-the-line is acknowledged.  This isn't an
issue with UDP. 
Hannes:  One of the reasons we created the SCTP transport for Diameter was
to address the head-of-line
blocking issue.  But SCTP has not been widely implemented.
Alan: For those that are interested, FreeRADIUS now supports RADIUS over
TCP, so you can play with it.
Bernard: Does the latest revision address Issues 315 and 316?
Alan:  Yes.
Bernard: OK.  If there are no open issues, then we could do another WG last
call.

RADIUS over DTLS

Alan:  RDTLS has been implemented in Stefan's RADSEC Proxy.  I am
implementing it as well. 
This draft was not revised. 
David Nelson: Isn't this draft expired?  What is the status?
Alan:  It is not expired.  
Bernard:  We issued a call for interest.  Only one or two people responded.
There are no
open issues at the moment.  We need more reviews.

IEEE 802 Attributes

Dan Romascanu:  Is this document only about WLAN attributes or wired IEEE
802 attributes as well?  Are
the attributes usable on multiple technologies? 
Bernard: A number of the attributes are specific to a technology.  For
example, there are attributes
that relate to IEEE 802.11r specifically.  There are also attributes that
relate to IEEE 802.1X-REV. 
Joe Salowey:  IEEE 802.1X-REV does apply to wireless, but there are aspects
(such as announcements)
that were only meant to be implemented on wired networks.  
Bernard:  At one point we had attributes specific to IEEE 802.11s, but the
security model changed, so
we removed them.  
David Nelson:  What is the status of the document?
Bernard Aboba:  IEEE 802.1X-REV has completed Sponsor Ballot.  We were
waiting until the resolution of
Sponsor Ballot comments to align the document with IEEE 802.1X-REV. 
Joe Salowey: IEEE 802.1X-REV is now going into recirculation ballot.  So it
is a good time to look at
it again. 
Bernard Aboba:  The document is referenced in Appendix E of IEEE 802.1X-REV.
But it is not a normative
dependency. 
Joe Salowey:  Now that IEEE 802.1X-REV has settled down, I will review the
document again, to see what
changes may be needed. 
Bernard Aboba:  After Joe is done with his review, what are the next steps?

Dan Romascanu:  For a standards track document, it can either be a WG work
item, or an AD sponsored
document.  I would prefer a WG work item.
Bernard:  There was a call for interest in November 2007, but it never
completed.  So the document has
been in limbo for almost two years now. 
David Nelson: Did anyone respond to the call?
Bernard Aboba:  Some people responded, yes. 
David Nelson:  I was waiting for IEEE 802.1 to send their requirements. 
Bernard Aboba:  IEEE 802.1 provided their review of -08 in July 2008.  That
is now up on the liaison archive.
David Nelson: We can either send the document to the RFC Editor or run a
quick WG last call on it, once
it is aligned with IEEE 802.1X-REV. 

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. 

Bernard:  Agreed.  To be clear though, this document does not currently
depend on Extended Attributes. 
Question:  If Extended Attributes were further along, would this document
use it? 

David Nelson:  It seems like there are a number of use cases here, and they
are not clearly described. 
Bernard:  Previous documents have had very well defined uses cases.  RFC
3162 supports address auto-
configuration.  RFC 4818 supports DHCPv6 Prefix Delegation.  This document
supports multiple modes,
and that is confusing. 

David Miles:  In looking at the attribute list, there are a set of
attributes relating to router advertisements
that require tagging, but another set of attributes like IPv6-Address and
IPv6-DNS-Server-Address that do not. 
Would it make sense to split the document into two parts, one focusing on
DHCPv6, and
the other one on router advertisements? 

David Miles: For the Broadband Forum, IPv6-Address is of the most immediate
interest.  IPv6-DNS-Server-Address 
is relevant but isn't as important since in most cases name resolution is
being handled over IPv4. 

Bernard Aboba:  If that is what you need, then focusing on that would enable
things to go forward much more
quickly.  Can you put a document together that focuses on that? 

David Nelson:  Which one? 

Bernard Aboba:  Yes, that document just handles the attributes you are
interested in.  However, it confused
the WG because it only talked about DHCPv6 and RADIUS, but did not talk
about authentication.  RADIUS is
spoken between a RADIUS client and server.  So if the RADIUS client is also
a DHCPv6 server, then it makes
sense.  But if the DHCPv6 server is separate, then it's not clear how it
works.  Does the NAS pass the
RADIUS attributes to the DHCPv6 server, and if so, how?  Is there
authentication going on between the
DHCPv6 server and the RADIUS server?  If there are no authentication
attributes is this a Call Check,
or is it changing the RADIUS protocol in some way?  

David Miles:  I can include material on the Broadband Forum scenarios.  If I
work with Benoit to create
an -01 with that additional material would that help?

Summary/Wrapup

Bernard:  At the last virtual interim, the feedback on DimDim was not very
positive.  So we tried LiveMeeting this time.  How did it work for people? 
Dan Romascanu: The conference bridge was fine. 
Alan DeKok:  I could not use the web conferencing software, it was only
available on Windows. 
Dan Romascanu:  It required me to install additional software (Outlook
addin).  That is a big deal. 
Bernard Aboba:  DimDim also required a software install.  Though it
supported more platforms. 
David Nelson:  Having a teleconference bridge, Jabber and slides is fine. 
David Miles:  As long as the slides don't get too long  or there are too
many people in the meeting.  Otherwise it's easy to lose your place. 
Bernard Aboba:  They had a session on WebEx at IETF 75, in the Working Group
Chairs meeting.  I asked the Secretariat if we could get access, but didn't
get a response.  So it was
either DimDim or LiveMeeting. 
Dan Romascanu:  I will inquire about the availability of WebEx. 

Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not
currently scheduled to meet at IETF 76.  We have just completed the Virtual
Interim, and 
IETF 76 is in just a few weeks. 
Dan Romascanu:  Who is attending?
David Nelson:  I will not attend. 
Bernard: No
Alan DeKok: No
Hannes: Yes
Dan Romascanu:  There are disadvantages to not holding a meeting at IETF 76.
You will miss the opportunity to interact with the community, particularly
participants from Asia.  
It would be good to have a representative at IETF 76.  Hannes is very busy,
but perhaps you can find someone to represent RADEXT. 
Bernard:  If there is WebEx available, we could participate remotely. 
Dan Romascanu:  I will look into supporting WebEx at the OPS Area Meeting.
There are cost concerns.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 23 Oct 2009 16:23:07 +0200

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

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

---

From: Alan DeKok <[email-masked]>
Date: Fri, 23 Oct 2009 17:26:49 +0200

> debacle, it would be appreciated if you could point to ones that were

  The datatype "debacle" can be more correctly described as:

Me: Here's a review that results in no functional changes, but allows
the specification to fit within the RADIUS data model, and to be
deployed with minimum code changes

You: We change nothing.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 Oct 2009 08:48:12 -0700

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: [email-masked]
To: [email-masked]; [email-masked]

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 23 Oct 2009 09:21:31 -0700 (PDT)

Hi Alan,
  In fact, before the Interim call we had made a revision to address all of your concerns and made  the specification to fit within the RADIUS data model, and to be deployed with minimum code changes as you wished.

Glen was expected to attend the call and state this. But I think he got sick and couldn't attend. 
Sigh.

I wish Glen a quick recovery.

Regards,

Behcet

----- Original Message ----
> From: Alan DeKok <[email-masked]>
> To: Wojciech Dec (wdec) <[email-masked]>
> Cc: Bernard Aboba <[email-masked]>; [email-masked]
> Sent: Fri, October 23, 2009 10:26:49 AM
> Subject: Re: Draft RADEXT Virtual Interim Minutes
> 
> archive:

---

From: Alan DeKok <[email-masked]>
Date: Fri, 23 Oct 2009 18:28:54 +0200

>   In fact, before the Interim call we had made a revision to address all of your concerns and made  the specification to fit within the RADIUS data model, and to be deployed with minimum code chang…

  I hadn't seen that revision.  My comments were directed to the
discussion on this list, and not about anything else.

  I believe that the functionality defined in the document is useful.  I
have no major concern with the document.

  Alan DeKok.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 23 Oct 2009 19:18:15 +0200

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; 
 
http://www.ietf.org/old/2009/proceedings/08jul/minutes/radext.txt
 
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)
 
RADIUS attributes for IPv6 Access Networks, Benoit Lourdelet
http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access
<http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access>  

a.	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! 
b.	Problem statement - RFC3162 needs additions to accommodate IPv6
production networks. Feedback is coming in from actual deployments. Need
flexibility. 
c.	IPv6 DNS location needs to be configured on a subscriber basis -
wholesale, VPN. 
d.	Implementation can happen in DHCP and SLAAC. 
e.	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. 
f.	More specific routes should be transmitted to the subscriber -
multi-homing, multiple attachments - see
draft-dec-dhcpv6-route-option-01. 
g.	Prefix lifetimes must be configured on a prefix basis. 
h.	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.

________________________________

	From: Bernard Aboba [mailto:[email-masked]] 
	Sent: 23 October 2009 17:48
	To: Wojciech Dec (wdec); [email-masked]
	Subject: RE: Draft RADEXT Virtual Interim Minutes

	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. 

	 
	
________________________________

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

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 23 Oct 2009 11:07:38 -0700

> debacle, it would be appreciated if you could point to ones that were

Please read the minutes of the RADEXT WG meetings (such as IETF 73) at which
the draft has been discussed. 

There was quite a bit of feedback presented at those meetings, most  of
which has been addressed.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 23 Oct 2009 11:22:09 -0700

Wojcejech said:

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

In looking through the minutes of the WG meetings I don't see any
indications that the draft was accepted as a WG work item.    

Within RADEXT WG, adoption requires a formal consensus call, which was
subsequently held (with insufficient interest being displayed so far). 

The IETF 73 minutes do provide an indication of the overall reaction to the
document, which included objections both in principle and with respect to
the specifics. 

I can post the individual comments made as Issues if you like. 

At the Virtual Interim, David Miles proposed an approach for overcoming
those objections and moving the document forward.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 23 Oct 2009 11:33:21 -0700

There was quite a bit of feedback presented at those meetings, most  of
which has not been addressed.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 23 Oct 2009 20:35:58 +0200

From: Bernard Aboba [mailto:[email-masked]] 
	Sent: 23 October 2009 20:22
	To: Wojciech Dec (wdec); [email-masked]
	Subject: RE: Draft RADEXT Virtual Interim Minutes

	Wojcejech said:

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

	In looking through the minutes of the WG meetings I don't see
any indications that the draft was accepted as a WG work item.    

	Within RADEXT WG, adoption requires a formal consensus call,
which was subsequently held (with insufficient interest being displayed
so far). 

	The IETF 73 minutes do provide an indication of the overall
reaction to the document, which included objections both in principle
and with respect to the specifics. 

	At the Virtual Interim, David Miles proposed an approach for
overcoming those objections and moving the document forward.  

	Woj> As per my earlier mail(s):

	- could you confirm that what my mail outlined in terms of
moving forward is also your expectation? 

	- Are you now convinced of "interest"? (and if not, or
partially, then on what grounds given the rather abundant amount of
contributors, reviewers, discussion?)

	- could you point out (summarise) the issues that were not
addressed?

	Thanks.

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 24 Oct 2009 08:17:11 -0400

Wojciech Dec writes...

> partially, then on what grounds given the rather abundant
> amount of contributors, reviewers, discussion?)

The level of interest required to accept a work item in the RADEXT WG is, as
you say, an "abundant" number of reviewers, not including the authors.
There is no hard rule, but half a dozen would be a good threshold.  The
success of any WG in producing quality documents is tied to the number of
members that are willing to actively review and comment upon the drafts.  Of
course, it also depends upon the authors providing timely and responsive
revisions.

I haven't taken a count recently, but excluding authors, I'm not sure I'd
use the term "abundant" to describe the number of independent reviewers.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Oct 2009 11:40:22 +0700

Dave Nelson [mailto://[email-masked]] writes:

...

> There is no hard rule, but half a dozen would be a good threshold.  

Not counting the authors, 19 individuals have posted on _any_ topic on this
list this year; discounting IESG members and WG Chairs (official and de
facto) brings the number down to 13, most of whom sent only one or two
messages (mostly regarding their own drafts).  So it sounds like you are
saying that about half the active WG members have to sign up to review the
draft, is that correct?  It's interesting how high the bar is set in this
case given that apparently _no one_ has ever actually reviewed
draft-ietf-radext-design (currently being emphatically pushed for
publication despite the number of egregious technical errors discovered upon
a reasonably close reading thereof).  

...