Page Comparison

Date and Time

• Date: Wednesday, 21 August 2013
• Time: 07:00 PT | 10:00 ET | 14:00 UTC
• Dial-in: United States Toll +1 (805) 309-2350
  
  •  Alternate Toll +1 (714) 551-9842
• Skype: +99051000000481
  
  • Conference code: 613-2898

...

1. Administration:
   
   1. Roll Call
   2. Agenda Confirmation
   3. Approval of Minutes: AIM WG Minutes 07-August-2013
2. Discussion / Action Item Review
   1. Further discussion of WG - Attributes In Motion - Roadmap Planning - AIMWG and assigning shepherds (Ken Dagg, Colin Wallis)
   2. Attribute registry requirements draft: http://tools.ietf.org/id/draft-johansson-areg-reqs-01.txt (Leif Johansson, Heather Flanagan)
   3. Periodic Table of Trust Elements (Ken Klingenstein)
3. AOB
4. Adjourn

...

• Propose to approve the minutes of AIM WG Minutes 07-August-2013 - Allan Foster moves, Keith Hazelton seconds, minutes approved

...

...

• there was a similar exercise a few years back when Leif helped establish an IANA registry for Levels of Assurance (http://www.rfc-editor.org/rfc/rfc6711.txt)
• we've seen several attempts at building internet-scale registries, so it is recognized as not an easy activity
• so, rather than start the registry itself, we are trying to spec out the requirements, isolating that discussion from how to represent the information or how to build the registry
• we have not received a lot of comments on this so far
• why was this an Internet Draft at all? for an attribute registry to work, it needs to be anchored to some existing organization or process that manages internet-scale registries, and there are only 2 - IANA and ICANN; if you want to set up a registry with these organizations, you need an RFC
• the document tries to make a logical, structured approach, the architectural aspects not the representational aspects
• Discussion:
  
  • there seems to be a few efforts; everyone who enters in to the attribute space seems to understand we need to have a dictionary, lexicon on what the attributes actually mean.  In this group, we've talked about the concept of metadata around attributes, because agreeing to the meaning of the attribute itself is only one aspect of understanding the attribute.  Levels of trust, context, more all fit in to actually understanding an attribute and how it could/should be used.  Is there space in the registry for this metadata?
    
    • Yes.  Identified as something that needs to be done, probably in parallel to the creation of the registry itself
  • when the document first came out, was fairly excited and surprised it got no traction because it is obvious that it is needed.  Still hoping this moves ahead, because the need has not gone away.
    
    • registries are a can of worm in many communities, because they imply a central point of control.  We are not trying to standardize on attribute semantics, we are trying to standardise on descriptions.
  • this is also a work item in the Scalable Privacy NSTIC grant.  They have started building data structures and compiling information, and while not going through the IANA registry process, it is something to start collecting the information.  Putting on the table what kind of information needs to be represented.  The native format they've come up with is an attribute registry based in an ontology tool (OWL).  But remember there are 2 tracks, the meta issue of whether we should do the registry and if so what are the requirements, and two, start doing the work to put it together.  This draft touches on the former, the Scalable Privacy grant focuses on the latter.  The administration has to be distributed somehow; Scalable Privacy is pulling it in from other specs.
  • this is a requirements doc - are there any requirements missing?
    
    • it depends on what the next steps look like.  Depending on how we want to talk about issues of metadata, for example, might muddy the waters. 
    • Discussing this in multiple communities is one important thing we need to do.  We could set up a common set of interfaces and APIs, just build it and they will come without requiring IANA.  However, if we want to run the registry as a central point of information, then we need to see if we have support for this in the internet community.  There are also processes for that within the IETF itself (Area Director support, possibly an IETF WG) that we will have to take in to account
  • what about the nay sayers?  what would they find problematic here? 
    
    • either you build something completely centralized, at which point people can't completely agree with and so will not use; or you build a non-centralized thing which turns in to a majorly complex entity requiring global discovery services.  OIDs are an example of the kind of complexity we're looking at.
    • the utility of attributes is going to directly relate to people being able to discover them, so this is really important enough to try
  • there is a fairly open space with respect to attributes; we know we need to understand what we're talking about if there is going to be real interaction, but nothing leaps forward as the obvious way to do things.  Setting up a registry is one path, but the registration path seems fairly arbitrary.  There is not an alternative - probably no single "right path" - so we need to do something.  Do still wonder what the role the additional metadata will play in the registration, since it is more than just the definition that needs to be defined.
    
    • that is probably a separate document (to describe the metadata); create a strawman metamodel and then a registry that can handle anything thrown at it as long as there are a few core facts (a name, an owner, that kind of thing)
• What are the next steps?
  • from this community, we would like answers to the questions in the documents - there are a number of choices in the document, and say "if I were to build one of these things, I would prefer A over B, C over D"
    
    • Keith to provide his answers based on the work done in the Scalable Privacy work and will send that to the list; Allan will also go through and answer the questions as well
    • remember it is equally important to talk about what is missed, if something is obvious as you go through it
  • need to think about what other parts inside Kantara should look at this; maybe IAWG and FIWG should look at this as well
    • let's keep it within the group until we've solidified some of what we've talked about today, then socialize with the other groups

Further discussion of WG - Attributes In Motion - Roadmap Planning - AIMWG and assigning shepherds (Ken Dagg, Colin Wallis)

...