[10:18:59] --- Dave Nelson has become available
[10:19:43] <Dave Nelson> test
[11:05:14] <Dave Nelson> Do we have a Jabber scribe in RADEXT currently?
[11:06:48] --- loughney has become available
[11:06:54] <loughney> Yes, I am jabbering
[11:07:01] <loughney> Document status
[11:07:04] <Dave Nelson> Thanks!
[11:09:15] <loughney> New IETF rule - need 4 non-authors to comment that they have read a document in order to pass WGLC
[11:09:38] <loughney> David Kessens - AD is taking lack of comments as a smoking gun of lack of interest.
[11:09:57] <loughney> Hannes - seems that people do things right before IETF meetings
[11:10:23] <loughney> Hannes - it is hard to read documents around IETF meeting time, because of document overload
[11:10:46] <loughney> Madjid - suggests to have reading clubs at the meeting.
[11:11:08] <loughney> Madjid - could you send a summary again to the mailing list?
[11:11:31] <loughney> Bernard - I did send the mail, twice!
[11:12:22] <loughney> RADIUS digest - Wolfgang
[11:12:58] <loughney> [presentations @ <http://www.drizzle.com/~aboba/IETF64/radext/> <http://www.drizzle.com/~aboba/IETF64/radext/> ]
[11:13:45] <loughney> Dave - I am not going to jabber the slides, just the comments, OK?
[11:14:02] <loughney> Glen Zorn - confused by the MPLS in the side (slide 2).
[11:14:18] <loughney> Wolfgang - it was mentioned by someone ...
[11:14:36] <loughney> Glen - cough / choke / laugh - at notion that MPLS provides encryption.
[11:15:08] <loughney> Security slide
[11:15:19] <Dave Nelson> Yes, just the comments are fine, thanks! Actually, I'm listening to the streaming audio, anyway.
[11:15:36] <loughney> Hannes - doesn't think that this scenario is any different, so just use normal security stuff.
[11:15:55] <loughney> Wolfgang - yes, that is the resolution - but this was challenged.
[11:16:48] <loughney> Miguel Garcia - I was the one who challenged this - you could put some ipsec co-located with the server. If you do it with tls, then it is integrated. if you are using ipsec, you might not know.
[11:17:37] --- mrichardson has become available
[11:18:13] <loughney> Bernard - do you agree with the resolution?
[11:18:16] <loughney> Miguel - yes
[11:18:20] <loughney> Diameter slide
[11:18:48] <mrichardson> if you don't know that you are using IPsec (and there are very few operating systems with IPsec built-in that fail to provide this information in an API!), and you don't have a toggle in your radius server configuration for the admin to indicate that there is IPsec, then you have built your server wrong.
[11:20:01] <loughney> Michael - is that a question for the mic?
[11:20:06] <mrichardson> no. I'm in the room.
[11:20:23] <loughney> I'm too busy typing to check :)
[11:20:24] <mrichardson> since there is no major disagreement with using IPsec.
[11:20:31] <loughney> ack.
[11:21:03] <loughney> Next presentation - Diameter SIP
[11:27:01] <loughney> Glen Zorn - comment on Issue 50.
[11:27:28] --- jschoenwae@jabber.org has become available
[11:27:45] <loughney> Glen - PPR - push profile request - someone wants to use this for accounting?
[11:28:05] <loughney> MG - yes, someone could update the URI of the accounting server with the PPR
[11:28:49] <loughney> Glen - OK, its OK - just a little confusing - "we'll use a command for a different function, but what the heck!"
[11:36:17] --- prkj has become available
[11:36:20] <loughney> MIBs
[11:39:32] <loughney> Dan: back to the counters issue.
[11:40:04] <loughney> Dan - there is a concern that this might give too much info out - security consideration should reference this.
[11:40:24] <loughney> Greg - that can be added.
[11:40:35] <loughney> Bernard - I believe these are being implemented now?
[11:40:49] <loughney> Greg - yes, there is a vender implementing them & the vender is happy.
[11:41:47] --- bert has become available
[11:42:39] <loughney> Bernard is channeling David.
[11:45:41] <loughney> Paul Congdon - Never change your domain password 1 hour before a flight ...
[11:48:38] <loughney> Discussion of splitting the document into 2 pieces.
[11:48:51] <loughney> Greg Weber - can you remind us why redirect was added this document?
[11:49:12] <loughney> Paul - there was always a redirect function, so it was thought that they could be combined.
[11:49:34] <loughney> Bernard - there's something about using the same syntax, but why add them to the same attribute?
[11:49:38] <Dave Nelson> We also decided tthat IP redirect would break things.
[11:50:23] <loughney> Bernard - right, but we don't have ip redirect in the doc.
[11:51:30] <Dave Nelson> laiming compliance on a per-RFC basis is convenient, but may create more documents.
[11:51:41] --- adekok has become available
[11:51:43] <Dave Nelson> Claiming...
[11:57:10] <loughney> Hannes - question about QoS filter rule - how does it relate to the bandwidth draft?
[11:57:29] <loughney> Bernard - this is about priority marking
[11:57:56] --- adekok has left
[11:57:57] <Dave Nelson> Right. I thought we had decided that QoS issues would be dealt with outside of RADEXT.
[11:58:05] <loughney> Hannes - these filters match to a QoS class
[11:58:07] --- Ralph Droms has become available
[11:58:28] --- adekok has become available
[11:59:37] <Ralph Droms> Where are we in the agenda? I'm stuck in ipv6.
[11:59:39] <loughney> suggestion is to move this into another draft
[12:00:04] <Dave Nelson> Talking about the "802" sttributes draft.
[12:00:05] <loughney> Dave Congdon's talk.
[12:00:30] <loughney> Ralph - when are you on the agenda? I don't have it in-front of me.
[12:00:30] <Ralph Droms> Thanks...
[12:01:33] <loughney> Hannes - when we looked at Diameter filters, we noticed it is not complete.
[12:01:47] <Ralph Droms> I think I'm 30 minutes later on the agenda. And, I think I can come over to radext now.
[12:02:04] <loughney> Bernard - if it is IPsec, then its encrypted
[12:02:07] <loughney> Hannes, yes - but it has header info
[12:02:10] <Dave Nelson> Ralph, you're about 30 minutes in the future on the agenda.
[12:02:32] <loughney> Hannes - what about ordering, overlapping filters, etc.
[12:02:48] <loughney> Bernard - filter rules can get mixed when going through a proxy, so ...
[12:03:09] <loughney> Jari - I know there is pain in the compatability, but he'd still like to have it.
[12:03:49] <Dave Nelson> It's probably Ok for RADIUS support to be a proper (well defined) subset.
[12:04:19] <loughney> Glen Zorn - I'd want to disagree with this. In general, Diameter compatability doesn't really exist.
[12:07:10] <loughney> Jari suggest that a superset is OK, but not to move in a different direction.
[12:08:35] <Dave Nelson> OK if you don't use the other header bits.
[12:09:46] <loughney> Dave - comment - bridge mib has a mib on vlans, and it is an integer
[12:10:23] <loughney> Bernard - defining accounting in a filter attribute is a bit odd
[12:10:42] <loughney> Paul - that issue is on the next slide
[12:12:14] <loughney> Bernard - the concern is that this attribute is becoming the attribute that ate Manhattan.
[12:14:43] <loughney> radius fixes draft
[12:16:01] <loughney> no comments
[12:16:05] <loughney> Design guidelines
[12:18:31] <loughney> show of hands of who read the 01 draft - about 5 or 6
[12:18:49] <adekok> me, too. (for what it's worth)
[12:20:50] <mrichardson> have just browsed this document, I'm pretty happy that it is occuring.
[12:21:28] <Dave Nelson> I've read it, too.
[12:21:28] <loughney> [you both should send notes to that affect to the radext list - or if you aren't subscribed, I'll channel you]
[12:22:08] <mrichardson> (in room) I'd actually like to see this work almost be done IETF-wide ---- what are common TLV formats, and which ones are good/bad/etc. let's avoid having this discussion ever again.
[12:22:13] <adekok> Yes. Issue 106 was raised by me, IIRC
[12:22:39] <mrichardson> ah, hi Alan. We've talked about making this IETF-wide before.
[12:23:30] <Dave Nelson> Well, yeah... but this RADEXT milestones needs to get done.
[12:23:54] <adekok> Draft is good starting point.
[12:24:26] --- mrichardson has left: Logged out
[12:25:16] --- mrichardson has become available
[12:25:20] <mrichardson> sure... point is... do this in radext, and then let's generalize it again at the IETF level.
[12:26:05] <loughney> Michael - that sounds like a fun plenary topic ...
[12:26:38] <loughney> Diameter NASreq & RADIUS compatability.
[12:27:10] <mrichardson> DHCP has TLV.
[12:27:11] <mrichardson> IKE has TLV.
[12:27:13] <mrichardson> EAP has TLV (done BADLY)
[12:27:24] <loughney> SCTP has TLV
[12:27:40] <adekok> Agreed.
[12:27:44] <mrichardson> I just want to create a palette of stuff that was done right, and stuff that was done wrong, so that when people do it wrong, I can say, "please read BCP XXXX"
[12:28:06] <adekok> FYI: Michael & I have talked about this for a number of years now.
[12:28:34] <mrichardson> we just haven't found an appropriate mechanism to start this work. maybe we should just an individual submission.
[12:28:55] --- adekok has left
[12:29:17] --- adekok has become available
[12:30:51] --- bew has become available
[12:30:52] --- bew has left
[12:30:59] --- bew has become available
[12:32:06] --- jschoenwae@jabber.org has left: Replaced by new connection
[12:35:56] <loughney> Glen - this just doesn't apply to vsa's - but to all RADIUS attributes
[12:36:20] <loughney> Max length of a Diameter is greater than max length of RADIUS
[12:37:17] <loughney> questions if you can maintain any compatibility without hamstring Diameter
[12:37:41] <Dave Nelson> It is important that RADIUS features be supportable in Diameter. The converse need not always be true. Else why do we need Diameter?
[12:37:58] --- loughney has left: Replaced by new connection
[12:38:08] --- loughney has become available
[12:39:23] * mrichardson still wonders why we need Diameter :-)
[12:41:09] <adekok> RADIUS has size issues independent of Diameter: Multiple "text" attributes, like 100's of Cisco-AVPAirs
[12:41:31] <adekok> Semantics of flags: how does this interact with capabilities problem statement?
[12:42:28] <mrichardson> loughney: reports that AAA will close down and create Diameter maintenance group.
[12:42:37] <mrichardson> "it's hard to be multi-protocol"
[12:44:21] <mrichardson> Alan's statement was a question:
[12:44:32] <mrichardson> (ASK) Semantics of flags: how does this interact with capabilities problem statement?
[12:44:45] <Dave Nelson> Like IPv6, use Diameter when the features support the applications you require.
[12:47:03] <adekok> Comment: RADIUS has size issues independent of Diameter: Multiple "text" attributes, like 100's of Cisco-AVPAirs
[12:48:15] <loughney> anyhow, I am back - so I might have missed somethings ...
[12:52:02] <loughney> Bernard - considers this a 3162 clarification
[12:55:09] <loughney> consensus seems to be make a 3162-bis & do it quickly.
[12:56:23] <loughney> Pasi - sounds like a simple thing & there is customer demand, make it an individual draft.
[12:57:26] <loughney> Ralph suggests doing his draft as an individual draft & incorporate it into a 3162 bis ...
[12:57:31] <loughney> Hannes supports it.
[12:57:38] <loughney> ISMS requirements
[13:03:15] --- jschoenwae@jabber.org has become available
[13:03:39] <loughney> Hannes - asked for clarification on how the mapping is done.
[13:04:47] <loughney> Bernard - cut the discussion, ISMS need to send requirements.
[13:05:14] <loughney> Management attributes - Greg
[13:07:50] <adekok> FYI: volunteers to review draft
[13:09:31] <loughney> Need to have some discussion with ISMS to see if the requirements are OK.
[13:10:09] <loughney> MIPv4 bootstrapping with RADIUS
[13:17:13] <adekok> slides are atslides for geepriv
[13:18:02] <adekok> slides for geopriv
[13:18:05] <adekok> http://www.xs4all.nl/~evbergen/ietf/ietf64_radext_geopriv_challenges.pdf
[13:18:48] <loughney> Jari - has some trouble with Case C slides. If a NAS doesn't understand challenge, it seems like you are trying to do something else ..
[13:18:57] <adekok> The issue of challenge is addressed in the next presentation.
[13:21:23] <Dave Nelson> I have a question about the basic RADIUS trust model and why GEOPRIV needs to be told by the AAA server when it can send location?
[13:21:49] <Dave Nelson> The issue is one between the Home AAA and the Client, and RADIUS trust is always hop-by-hop.
[13:22:19] <adekok> I agree. See the last slide in my presentation.
[13:22:31] <loughney> i'm going to the mic
[13:23:35] <adekok> Glen Zorn: capability problem needs to be addressed in a wider context.
[13:23:58] <Dave Nelson> While there may be a legitimate need for capabilities, I wonder if the GEOPRIV usage is required?
[13:24:30] --- prkj has left
[13:24:51] <Dave Nelson> Proxy servers can lie.
[13:25:49] <Dave Nelson> The Home AA server probably does have the policy, but RADIUS trust is hop-by-hop.
[13:26:14] <adekok> hannes: assumption is that some trust in AAA is involved..
[13:27:03] <loughney> moving on.
[13:27:46] <Dave Nelson> We can't change the way RADIUS works, but is the way it works suitable for the security considerations of GEOPRIV?
[13:28:02] <Dave Nelson> I should make thse comments on teh lists...
[13:28:38] <loughney> Bernard is now Alan
[13:31:11] <adekok> yes. Superset
[13:31:38] <loughney> OK, superset.
[13:34:37] <adekok> Emile & hannes worked on the previous presentation
[13:35:14] <loughney> Hannes - not sure if it is necessary to take a simple problem and make it complex.
[13:35:54] <adekok> This presentation minimizes communications problems as seen on the list.
[13:36:36] <adekok> Yes, thanks.
[13:36:46] <loughney> Hannes doesn't believe it.
[13:37:00] <loughney> Bernard says take it to the mailing list.
[13:37:11] <loughney> AD time
[13:37:41] --- bew has left
[13:37:58] <loughney> David is concerned because the charter & milestones are not being met. How do we meet them? If we cannot meet them, why take on new work?
[13:38:02] <loughney> Any ideas?
[13:38:16] <loughney> Hannes - David, what is the problem for the delay?
[13:38:55] <loughney> David - this isn't my point to answer, it is the working group.
[13:39:15] <loughney> David is worried about the RADIUS design guidelines, this should be done early on.
[13:39:33] <loughney> It is causing problems in the wg.
[13:40:10] <loughney> There are 2 categories - stuff that requires guidelines and ones that don't - milestones that are completing don't need the guidelines.
[13:40:42] <loughney> Bert - co-ad -.the major problem is that old deadlines are staying there, but new items are being prepared.
[13:41:43] <loughney> Glen - the milestones were artificially constrained, so if the wg actually worked on the charter then things would look better.
[13:42:12] <loughney> sorry, but I've got to drop out now.
[13:42:29] --- loughney has left
[13:43:02] --- rbless has become available
[13:43:30] --- Ralph Droms has left: Disconnected
[13:43:31] --- rbless has left: Lost connection
[13:47:31] --- adekok has left
[13:47:57] --- jschoenwae@jabber.org has left: Logged out
[13:49:29] --- Dave Nelson has left
[14:11:10] --- bert has left
[14:57:08] --- mrichardson has left
[15:37:57] --- loughney has become available
[15:38:05] --- loughney has left