Re: [radext] RADEXT @ IETF82: Draft meeting notes

["Sanchez, Mauricio (HP Networking)" <[e-mail]>]

You get a gold star.

Master copy updated.

Thanks,
MS

-----Original Message-----
From: Alan DeKok [mailto:[e-mail]] 
Sent: Tuesday, November 15, 2011 6:27 PM
To: Sanchez, Mauricio (HP Networking)
Cc: [e-mail]
Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes

Sanchez, Mauricio (HP Networking) wrote:
> It was a small test to see whether people actually read the notes.   You passed. 

  I'm referred to as "Allan".  A reference to 4284 should be changed to 4282.  "claify" to "clarify"

  Do I get a cookie?

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Klaas Wierenga
> Sent: Tuesday, November 15, 2011 5:41 PM
> To: [e-mail]
> Subject: Re: [radext] RADEXT @ IETF82: Draft meeting notes
> 
> On 11/15/11 10:25 AM, Sanchez, Mauricio (HP Networking) wrote:
>> Below are the draft notes for our meeting at IETF 82.  Any corrections/modifications welcome.
> 
> no biggie,  but see below
> 
>> -MS
>>
>>
>> --------------------------------------------------------------
>>
>> RADEXT WG Minutes
>> IETF 82
>> Taipei, Taiwan
>> Monday, November 14, 2011
>> Meeting started 9:02AM and ended 10:32AM.  Approximately 17 
>> individuals in meeting
>>
>> Chairs:
>> Jouni Korhonen<jouni.korhonen at nsn.com> Mauricio 
>> Sanchez<mauricio.sanchez at hp.com>
>>
>> AD:
>> Dan Romascanu<dromasca at avaya.com>
>>
>>
>> 1.Preliminaries
>> -Chair asked for jabber scribes (Stefan Winter) and note takers (Dorothy Stanley, Aruba Networks volunteers).
>> -Chair reviews the agenda. No proposed changes to agenda as shown 
>> below -WG Goals/Milestones status -Chair reviewed status of documents 
>> that have been published, that are waiting for write-up, that are in 
>> last call, in
>>
>> progress, under review as WG item, Interesting work outside of current charter.
>> -Are there any volunteers to shepherd the TLS encryption for RADIUS? 
>> Will put a call out on the list, if no volunteers,
>>
>> one of chairs will volunteer.
>> -Will another last call be required after the current one for RADIUS attributes draft? To be determined.
>> -RADIUS over DTLS - Allan will work on to advance.
>> -NAI-based peer discovery - planned to align with RFC, RFC now 
>> published -IEEE 802 attributes - Bernard picking the draft up again, adopt as a WG item, make the draft active again.
>> -NAI - Allan working on it, will discuss changes, and consider 
>> adopting as a work item
>> -2 drafts for RADIUS accounting
>>
>>
>> **********************************************************
>>
>> 2. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec 
>> -http://tools.ietf.org/html/draft-ietf-radext-ipv6-access
>> -See http://www.ietf.org/proceedings/82/slides/radext-1.ppt
>> -Leaf Yeh: How is the use case for DHCP addressed?
>> -Woj Dec: Attributes for name pool - DHCP.
>> -Woj Dec:Next step is to submit next version with editorial comments, corrections.
>> -Leaf Yeh:Question on name of pool on the mailing list.
>> -Woj Dec: Interpret pool names as such. Solution is to have a different attribute for the pool - stateful-ipv6-address- pool-attribute. Format is the same, but is different attributes; one for local, one for delegated.
>> -Leaf Yeh: Suggests one pool name for all addresses - need to determine how to use the names. Or create complex pool of all attributes.
>> -Woj Dec:Current conclusion is not to do anything.
>> -Woj Dec:If use existing attribute, - server has to interpret the pool name as belonging to a specific type.
>> -Bernard Aboba: Roaming deployments - may use a pool name, need to make sure you have same behavior across providers. Need to be explicit, so don't have chaos, can debug issues.
>> -Chair: Consensus is that the current attribute and semantics are 
>> necessary to not introduce ambiguity
>>
>> ************************************************************
>> 3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh 
>> -http://tools.ietf.org/id/draft-yeh-radext-ext-traffic-statistics-01.
>> t xt -See http://www.ietf.org/proceedings/82/slides/radext-2.pptx
>> -Describe difference between version 6 and version 4.
>> -Summary of requirements, IDs, network scenario, attribute design (8 
>> new attributes), enhanced design -Stefan Winter: Use TLV encoding as in extended attributes draft - everything on one attribute.
>> -Leaf Yeh: Still not sure about container attribute (Stefan Winter 
>> draft addresses) -Leaf Yeh: Does this deserve to be a WG item? Seem to have clear requirements from the industry.
>> -Stefan Winter: Concern - have many drafts on this topic, they seem to die out for lack of interest, then a variation appears.
> ^^^^^^^^ I think that was me
> 
>> -AD:Why not get together and resolve differences, and come back with a single proposal. What is the benefit of coming up with yet another proposal?
>> -Leaf Yeh:In last meeting (Quebec), didn't know how to define a new attribute using the extensions. Got feedback on the design.
>> -Stefan Winters: Are you saying that extended attribute is not the right way?
> ^^^^^^^^
> ditto
> 
>> -Leaf Yeh: Don't know. Can be done with traditional attribute design.Don't disagree. Thought that we as a group came up with better ways of doing this. Would like to follow-up with the "fancy accounting" method is not used.
>> -Stefan Winter:Distinguish between requirements and design.
>> -Multiple design approaches can solve the problem.
>> -Alan DeKok:Extended attributes draft was created for a reason - use complex attributes with a lot of content; define container, avoid stuffing several items into one attribute. Some of proposed designs still use complex encoding.
>> -Stefan Winter:Do you accept design 4?
>> -Leaf Yeh:No includes too much complexity - better to use explicit format.
>> -TLV nesting and grouping (Design 3)  - what is the benefit of this design?
>> -Benefit is that it uses the framework that the extended attribute defines. Reusable code.
>> -Also need new sub-attributes defined here.
>> -Need one set of new attributes and one type descriptor regardless. Use parser for extended attributes.
>> -In design 4 - use one field to introduce field type. Complexity is the same.
>> -Need to write a parser for this specifically. Better to use the framework.
>> -There can be multiple instances of attributes. In that point, the two are the same. In design 3, don't need another parser.
>> -Alan notes that Design 3 slide is wrong - attributes can be in any order. More flexible framework, just extract attributes, In proposal 4, have to care about the order of the attributes. In Design 3, can leave out some sub-attributes.
>> -Chair: Do you support this work in RADEXT?
>> -Is this needed for IPv4? Traffic type code can indicate the IPv4/IPv6 type.
>> -Should I migrate all IPv4 to this new format? BBF request uses original attributes for past traffic.
>> -Chair: Is anyone against having an accounting document? No objection. Ask authors to work out a single proposal. Need to determine if we bring into a new charter.
>> -AD: before we develop the contributions, ask authors to put together 
>> pros and cons of options, remaining points of disagreement. See if we 
>> can get agreement on a baseline proposal
>> -Chair: Consensus check on adding this topic to the re-charter: Show of hands on who is interested and will participate in the effort? 4 - yes, 0 - against. Will take to list, strong consensus to update the charter and make this a working group item. Ask authors to work towards a unified proposal.
>> -AD:Will this be discussed at the Paris meeting?
>> -Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step.
>>
>> ******************************************************************
>> 4.RADIUS Attributes for IEEE 802 Networks, Bernard Aboba 
>> -http://tools.ietf.org/id/draft-aboba-radext-wlan-15.txt
>> -http://www.ietf.org/proceedings/82/slides/radext-5.ppt
>> -Bernard: Purpose to add attributes required in 11r, and 802.1X key usage.
>> -Call for adoption was issued Nov 13, 2007. Yesterday was the 4 year anniversary.
>> -Does it need more time to ripen (like fine wines)?
>> -Should have moved a little faster - others adopted parts.
>> -What kind of attributes - from extended attributes? If move forward, ask this.
>> -Need to look at use cases for attributes also. First step is to adopt.
>> -EMU has finished WGLC on EAP lower layer. EMU would like input on collapsing lower layers together. Differences between 802.1X-2004 and 802.1X-2010.
>> -For the adoption of this document. If wait for it to be completely right, might be a long while. Also 11u extensions too.
>> -Unfortunate that document didn't advance - chair was side-tracked, but don't want chair's pushing their own agenda.
>> -Chair: Is there interest to adopt this document to address milestone: 12-yes, 0-no.
>> -Take to mailing list to confirm. Strong consensus to move forward.
>>
>> ********************************************************************
>> 5.RADIUS Protocol Extensions, Alan DeKok 
>> -http://tools.ietf.org/html/draft-ietf-radext-radius-extensions
>> -See http://www.ietf.org/proceedings/82/slides/radext-3.ppt
>> -Review of status, implementations (test vectors available - please 
>> use and review) -Comment on IANA section - IANA is a mechanical operation. Can't use normative language. Talk to Michelle and the IANA people, to see what they can really do. Provide extremely clear guidance.
>> -Believe updated text addresses that.
>> -What is the base policy - IETF consensus or greater. Add a note that not changing IETF policy. Updates RFC3575, or not?
>> -Need to state and be clear if policy is updated.
>> -Alan to prepare next version - will come out late this week or early next week.
>>
>> *********************************************************************
>> 6.Network Access Identifier, Alan DeKok
>> -http://tools.ietf.org/html/draft-dekok-radext-nai-01
>> -See http://www.ietf.org/proceedings/82/slides/radext-4.ppt
>> -Review rationale for the proposal (why") DNS affects EAP and RADIUS - why?
>> -Is there a Unicode 3.1 dependency here? On a reading of 4284, unassigned code points are forbidden.
>> -Cannot use a codepoint newer than 3.2.
>> -DNS look-up required separate conversion. Do DNS protocol requirements to turn string into something acceptable to DNS.
>> -No one implements any of the requirements of RFC 4282! Rather, treat username field as an opaque blob. 4284 is blocking progress - abfab documents require use of nai, but 4282 requirements cannot be used.
>> -Sam Hartman: Dependency in abfab on 4282 - 1 is a bug, will be removed in abfab; the second - need a "username" and "realm" item. Disagree that 4284 is blocking abfab. But needs to be updated anyway.
>> -Stefan Winter:Dynamic Discovery draft went through the same process.
>> -Alan Dekok:Some operating systems don't send UTF-8 characters. More 
>> reason to use nai-bis
>> -2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP.
>> -AD: Clarify - is the request that 4282 as historical/harmful, and 4282-bis on RADEXT work plan?
>> -Stop the confusion first - encoding out of scope.
>> -Stefan Winter: Is anonymization still there? "Left part" blank. Is it still in? Need to check - believe it is valuable.
>> -Chair: hearing consensus to work on this. Poll: Killing 4282  a good thing? 10 - yes, 0-no. Strong consensus to put a document out, put on the mailing list to confirm. Discuss on the mailing list the scope of 4284 -no-longer-applicable-versus internationalization.
>> -Adopt Allan's document? Other approach? To discuss on mailing list.  Sam to create text in abfab to claify purpose of 4282.
>>
>> *********************************************************************
>> 7.Next Steps: WG Chairs&  ADs (15 minutes) -Chair summarizes next 
>> steps re: updating the charter and what was agreed in the meeting.
>> -Chair reviews current goals and milestones, updates:
>> -Update IPv6 access to 2011 Dec
>> -Radius over DTSL - update to 2012 March -RADIUS Cryptoagility - 
>> update to early 2012, or March 2012.
>> -Extended attributes - update to March 2012 -IEEE 802.11 attributes - 
>> update to June 2012 -Dynamic Discovery - DIME version published, 
>> March
>> 2012 -RADIUS accounting - Sept 2012
>> -4284 bis - March 2012 for near term deprecation of 4284, - will be 2 different milestones, one for near term, one for longer term.
>> _______________________________________________
>> radext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
> 
>