[ieee-ietf-coord] Rough Notes from 2013-03-16 IAB/IESG/IEEE 802 EC Meeting

[Cindy Morgan <[e-mail]>]

Rough notes are below; a cleaned-up (hopefully more coherent version) will be posted to the Coordination list sometime in the next week or so.

Best regards,
Cindy

Rough Notes from the meeting between the IEEE 802 Exec Com, the IESG, and the IAB, 16 March 2013

Wiki: http://trac.tools.ietf.org/group/iesg/trac/wiki/2ndIEEE802andIETFleaders

9:00-9:30AM Introductions (including new IESG and IAB members), goals of the meeting

- Jari and Paul introduce the purpose of the meeting and thank everyone for coming.

- Bernard Aboba
- Jari Arkko 
- Stewart Bryant 
- Ross Callon
- Benoit Claise 
- Subir Das 
- Spencer Dawkins
- Ralph Droms
- Lars Eggert 
- Adrian Farrel
- Stephen Farrell
- Don Fedyk
- Heather Flanagan
- Howard Frazier 
- Eric Gray
- Brian Haberman 
- Joel Halpern 
- Bob Heile 
- Russ Housley
- Tony Jeffree 
- Bruce Kraemer 
- Eliot Lear
- Barry Leiba 
- Ted Lemon 
- Xing Li
- Mike Lynch	
- Roger Marks
- Karen McCabe
- Steve Mills 
- Apurva N. Mody 
- Cindy Morgan 
- Paul Nikolich  
- Glenn Parsons		
- Pete Resnick 
- Max Riegel 
- Buzz Rigsbee 
- Jon Rosdahl
- Dan Romascanu 	
- Dorothy Stanley	
- Martin Stiemerling
- Michael Johas Teener 
- Dave Thaler 
- Pat Thaler 	
- Geoff Thompson
- Hannes Tschofenig
- Sean Turner
- Juan Carlos Zuniga 


9:30-10:00AM - Status of 4441bis (Spencer)
http://www.iab.org/wp-content/IAB-uploads/2013/01/RFC4441rev-status-as-of-IETF-86-v2.pptx

[Spencer]

- RFC 4441 described the 802/IETF relationship as of 2004 or so.  Lots of water under the bridge, lots of new work.  There's a canonical list of topics for coordination, there were about 5.  Now there are about 20.

- At the meeting last summer we reviewed coordination topics and agreed to revise 4441.

- The target audience for this doc is 802 and IETF participant who are working/proposing new works in one of the orgs on topics that may overlap or conflict who may not be familiar with the other organization but need some guidance.  Nots binding on either IETF or 802.

- Publishing doc on the IAB stream, just ended IAB Last Call.  Early review comments from 802.11.  Starting to get comments on IEEE side, mostly straightforward.  A couple are less straightforward.

- 03 version includes descriptive test of how the IETF works.  Not 802-specific.  Line between just pointing to the BCPs versus "please tell us more."  Concern with being misaligned with BCP text.

- Proposed solutions want to say something.  Tao of the IETF is general guidance; not designed for 802 people who are sending liaisons to IETF. 

- Major surgery to replace generic IETF descriptive text with pointer to BCP.  802 sections also have descriptive text.  

- Minor surgery to review and look for what is imprecise and leave compare/contrast in the body of the text.

- 03 version of draft describes how each org notifies the other, but structure isn't that helpful.  Proposal is that we have liaison relationships for most existing work.  Each group initiation work will notify other SFO.  Use new-work mailing list.  Neither SDO needs monitorthe other WG's mailing list.  Other SDO responsible for identifying affected groups.  All else fails, anyone can talk to anyone as a heads-up.  New-work mailing list is only the beginning; coordination calls every six weeks are so have been very important.

- Mismatched levels of documentation.  IEEE has added a page listing liaison relationships to match IETF equivalent page.  But we may not want perfect symmetry; how long do we wait for more fixes.

- Intended path forward is to resolve comments received to date and issue Community Call for Comment.  Anyone may comment, expecting other 802-side comments during this, but don't need to wait for that.  Questions are: is 802 planning to ballot this, or just provide comments.  One of the things strange about 4441 is it had 1 author from IAB and no indication anyone from 802 agreed with it.  Could 802 provide a note about their agreement.  To be published as an IAB-stream RFC, aiming to finish by June 2013.

[Q&A]

- Thinking on the 802 side what to do about the doc, and think we should add something to the chairs' guideline that this RFC documents the relationship between the 2 organizations.  I think when we add something to chair guidelines the EC votes on it, and that would get it into our procedures.

- Needs to be some formal linking of 802 to this doc.

- Would like to see 802 EC issue a liaison saying we've read it and endorse it.

- There is one section which is described as notifying the other party of new work items, and I'm concerned by that.  There is an editing process going on.  I think there is still some deficiencies in way we notify other parties about new work items.

- If the 802 would like a statement in the doc itself, that is something we can do in the RFC.  IESG can add a note, so we have a process to add a note from another organization on the front page, so if that works for 802 then that is what I would suggest.

- Pat says that the above sounds like a good idea.

- You end up reading a lot to find the things that are helpful in liaising with another organization rather than participating in it.  So this explains in short form what is most useful in the liaison process.  So I'm pretty happy with the amount of content we have in there.

- Spencer thanks IEEE for their help in revising the doc.

- Paul noted that the conference calls were very beneficial, as are the face-to-face meetings.  So will need to figure out how to get together on a semi-regular basis.


10:00-10:45AM - Status of the Shared Areas work (Dan, Pat)
http://www.iab.org/wp-content/IAB-uploads/2013/01/Status-of-the-Shared-Area-Work.pptx

[Dan]

- Not going to do a full review of the list in this meeting, just a recap of what has happened since last July.  Suggestion about continuation in an number of areas. 

- Currently 20 items.  A few have been closed.  A few are new.  And we have a waiting list of things to pick up.

- [See slides (listed above) for full list of work items.]

- Re the MIF work [13 on shared items list], there is a proposal from Orange to keep it on the back burner.  Ted Lemon will be taking over from Ralph.  Leave the informational doc aside until the architecture is finished.  Communication will keep going on but it is going in the right direction.

- Re shared items 16-18, concern about getting people involved to do the work, lack of participation or coordination between the groups.  Suggest more teleconferences.

- Brian notes that he asked for a liaison statement in NTP.

- Stewart says the tricky part is the layer violation, ignored in 1588 when designed the first time.

- Re item 20 on TRILL, no actions specifically requested of 802.11.  What is expected?  If all social conversation and no action, is there a chance for TRILL to become a control protocol in this space. Should this item be kept open?  There is no formal request, and no work at this time.

- Dan suggests closing item 20.

- There are a few other items being considered for the shared work items list.

- Request to keep tracking closed items so we can tell why it was closed--was the work completed or dropped or whatever.

- Pat notes that the list itself (rather than the slides) has more information on the closed items and shows the record.

10:45-11:00AM - coffee break


11:00-11:45AM - Processes and communication between the IETF and IEEE 802 - what we learned in the last eight months, what can be improved (Dan, Pat)
http://www.iab.org/wp-content/IAB-uploads/2013/01/Processes-Communication_01.pptx

- Had a number of meetings.  One leadership meeting, 4 virtual meetings involving a sub-team of participants.  Maintaining the list of collaboration items, 20 items open, 3 closed.

- Using Wiki as a communication channel, and the [e-mail] email list (which is a closed list).

- Clarified critical issues raised by 802.1 and brought them within the scope of the other shared and liaised topics, no hot potatoes at this point.  

- IETF and IEEE-SA cooperated and are founding entities in OpenStand.

- Lessons learned: communication is essential, finding the right people, the right channels, and the right timing.  People are busy and each organization works at its own pace.  

- Need to understand the culture and processes of each organization.  Working on this with 4441rev.  

- Finding the right balance between formal and informal communications

- Ways to improve: raising the priority of the requests for reviews from the other org.  Concerns about response time, communication about the new PARs came to the IETF and new-work last Monday--the first day of the IETF meeting.  Doubtful anyone from IETF has had a chance to look at it yet.

- Paul explained that the info was known 30 days in advance and should have been communicated to the IETF sooner.

- In some other cases, a doc in review in Sponsor Ballot or IETF Last Call, each of them have timing.  Getting response in time and getting the docs reviewed is critical.  Not sure we've found the right watt to draw the attention when sending communication to the other organization to raise the priority of items.

- 802 says they know when they will have new work items because everything is on a schedule; how does it work on the IETF side with new-work.  IETF sends external reviews whenever they are relevant they send the announcement to new-work; can happen at any time.  The problem is that the external review period is very short.

- Jari notes that there is lots of internal discussion on new work, it can go on for months, but once it is ready for external review things move very fast.

- Russ notes that the messages we get on new-work from 802 are a direct result of the meeting we had last summer.  BOF scheduling happens ~30 days before the IETF meeting.  We could send a message to the coordination list as soon as we know which BOFs were considered and approved.

- Issues about transparency, awareness about the other organizations and the coordination program is rising, but yet insufficient.  Dan wonders whether things can be done to improve the situation, e.g. an IETF Journal article of a tutorial by IETF at the IEEE plenary.

- Paul likes the tutorial idea and notes that there is an open slot on their tutorial agenda in 2 days :-)

- Generally agreed that an IETF tutorial at a future 802 meeting would be good.  Note that there might be an opportunity in Geneva to also educate ITU people.

- Pat notes proposal on IETF tutorial in Geneva on congestion management.  Looking forward to that kind of collaboration.  

- An opportunity for mow than one tutorial, thinking about 4441, also other technical topics.

- Pat notes that IETF has a newcomers' organization, considering something similar in 802 but has a hesitation that technical tutorials tend to pull a bigger crowd than the process tutorials.

- Liaison tools, Spencer and Eliot working on a requirements draft for a new tool, will run by IEEE as potential users of the tool.  Not sure if IEEE has a similar liaison tool.

- What's next?  Have the virtual meeting sheen useful (yes).  Propose changing the frequency of the conference calls: interact by email, have conference calls 3x a year approx. 1 month before the earlier of the IETF or IEEE meeting.

- Frequency of face-to-face meetings: 1x a year, 2x a year?  Paul says his instinct is roughly once a year.

- Ross says once a year sounds right to him, but probably should not be the March IETF meeting when there is leadership changeover.

- Eliot responds that having both incoming and outgoing ADs at the F2F helps with transition and context.

- Russ says that the coordination phone calls have taken a lot of the sting out of the problems.  We are still communicating--but it is still important to have the F2F meetings.

- Pat says the logistics of once a year is difficult; don't have another convenient opportunity.  Thinks once every 2 years is enough to get people together F2F.  

- Jari says continuos work will solve many of our problems.  Think about length of meeting and frequency of meetings.  Could have targeted groups for specific topics.

- Jon notes that one of the reasons this week worked out so well is we were able to do coordination with the details.  As we look at the leadership in looking at our locations, we can work with the venue properties to gain a benefit.  More power when negotiating together, mutual benefits. 

- Paul notes that both groups have had a single point of contact (Dan and Pat), a person who has all of the context, and would like to see that continue.

- Sean asks for metrics on how much overlap there is in the meetings, considering the back-to-back schedule in the same location.  Russ says we will have the information after this meeting.

- Buzz notes April 2016 in Europe as a possibility.

- Ross/Lars suggest November 2014 Hawaii.

[Meeting dates and locations.  Will follow up offline on this topic.]

- Fee waivers to participate in each others' meetings = good.

11:45AM-12:00PM - Recent End-Runs on IETF and IEEE 802 Standards (Russ)

* Russ presents:

- 2 interpretations of WTO rules re who can set standards that are mandatory.  Hoping to increase the amount of work necessary to create a conflicting standard in one of these accepted SDOs or reduce the effort to stop them doing that.  

- 802 uses ISO for standardization; W3C has just started doing that.  Doc in the 8802 series are not the more recent versions.

- 802 submitted a lot of docs, in process of erupting engagement with ISO.  Level of engagement ramped up drastically in the last year.

- IETF / ISO relationship is different; IETF doesn't submit to ISO for ISO for ratification.  Many years ago tried to establish a Class A liaison relationship which was rejected.  A Class A between ISOC and SC6 is what we have today.

- Question re how much effort is involved to ratify standards in ISO.  Answer: 7 months of balloting, having to stand up and defend standards in ISO meetings, phone calls, travel money.  In terms of disruption of the standards per se, there is none.  But a significant amount of manpower needed to support the submission process.  1/10 man-year per year.

- An official agreement between IEEE and ISO about how they will handle IEEE standards when they are submitted, which includes that they are posted just once.

- Level of threshold in pain in receiving, all of the receiving bodies have to vote on what is received twice (should we consider, and if yes then yay or nay)

- 802 interest in getting legitimacy with ISO in respect to [] program.  

- Question whether IETF considered submitting to ISO.

- IETF went to JTC1 level and was offered a fast track for assignment of ISO numbers, counter-offer was rejected.

- Conflict is a spec becomes a national standard.  National standard submitted for fast track processing has no check for collision with multi-stakeholder standards bodies.  big effort to educate governments about the impact about these collisions with IETF or 802 standards.

- IETF support for national algorithms, public pointer to algorithm definition required but documentation need not be in an RFC.

- Conflicts in ISO.  WAPI proposal includes Chinese proprietary encryption and key management.  Major effort by IEEE 802 to prevent approval.  Also in ISO.IEC JTC1/SC6 specs using Chinese cryptography, TIsec.

- Dilemma that you have to get something in to pre-empt something coming in in its place.  But arguably is worth it--see WAPI.

- Russ says IETF is grappling with amount of energy necessary, but isn't there another way to get these organizations to work with us when there is a collision rather than just say that we're not a recognized SDO.

- IESG and IAB response to TIsec, discussed with 802 leadership.  Sent a liaison to ISO saying to not develop an alternative to IPsec.  Received request to assign a protocol number for the competing standard, and we said no thanks.  Suggested better to specify use of Chinese cryptography with IPsec.

- Small effort for a nation to submit a colliding standard but a  huge response for multi-stakeholder org to defend it; how to increase task of submission or create form of education for governments that do the balloting.

* Discussion

- EU discussion about what is mandatory.  Multi-stakeholder Platform (MSP) that IETF and IEEE participate in.  The European Commission is coming to us for advice on the ICT rolling plan for Europe.  Looking for advice on policy.

- Russ notes that it's an RFC-by-RFC basis, so can be cumbersome.  Effort is significant.

- Glimmer of hope in the UK that announced their properties than an SDO must have to reference their documents was in line with OpenStand (with exception of requirement for royalty-free).

- 802 has many years of experience with ISO, willing to have a small team sit down to talk about this and help IETF come up with a plan of action moving forward.  The next SC6 meeting where many of the security topics will be discussed.  There is material relevant to the subjects Russ presented in the June meeting in Korea.  IPsec is on the list of topics to discuss; is there a message 802 can take back?

- Russ: thrilled to review and make suggestions.

- Warning to not read too much into the choice of words in the UK procurement standards.  

- Question about whether ISO is an intergovernmental body?  But not all governments would agree with that.  Need to organize a matrix of countries and terms and definitions of each cell because what an open standard in Britain means is different from somewhere else.  Need to have the positions of both IETF and IEEE in response to those actions.

- Uruguay round (WTO treaty) mentions ISO.

_ Stephen asks who from IEEE is interested in national cryptographic algorithms.

- Even at the European level they don't have a requirement on royalty-free on open standards.  Disconnect there.

- Russ participated in a NIST workshop for ONB on circular A-119 defining requirement for a regulator in the US to point to a standard at turns out the royalty thing has multiple dimension.  American Bar Assoc. says if a regulation references a standard, then that standard must be downloadable from the internet for free, and all the medical guys freaked out because they sell them for as much as $45K.  Over $100K for a book and all its normative references.  

- Russ asks if IEEE has had a reduced number of end-runs since putting standards into ISO.

- Paul says to ask the end-runners, because it is tough to answer.  Think it has increased the cost for end-runners.

- 802 has seen an increased level in willingness to participate as opposed to trying to do things outside of 802.  Think that is the ultimate objective--get the work done where it should be done.

- Russ noted Chinese participation increased from ~2%-11% in the last 10 years; ITU-T is at about 30%.



12:00-1:15PM - lunch (the core leadership teams will meet in executive session during lunch)

- Discussed ways to deal with end-run situations and get global recognition and avoid duplicate standards.  IETF and IEEE 802 are taking different approaches to ISO, need to analyze that better and will do so offline.

- Multiple situations where we have to do this, submit docs to ITU, ISO, ANSI, EU, etc so they can be referenced in procurement documents.  If we are forced to do some of these things should we do it once (group all RFCs together and submit at once.)

- Strength in numbers, if both organizations do the same thing we may have a stronger position in negotiating some of the deals.  



1:15-1:45PM - OmniRAN Study Group (Max Riegel)
http://www.iab.org/wp-content/IAB-uploads/2013/01/omniran-13-0011-01-ecsg-omniran-introduction-and-way-forward.pptx

- OmniRAN is about attaching terminal devices deploying IEEE 802 technologies.  Trying to define common functionalities.  

- In the legacy worlds, talking about a single interface into a host, into a terminal.  Single operators controls service change, corporate IT department.

- A couple of new things, breaking the legacy understanding.  Hosts with multiple network interfaces (MIF), trying to define what is going on there.

- Scalability and deployment issues going further.  Terminals having multiple identities or subscriptions.  Which subscription can be used in which location.  Domain where IEEE is expanding the understanding.  New kinds of networks coming up: home automation, in-car comms.  Huge market for 802 docs.  Going into the technical domain, it becomes visible that the same old networking issues are coming up.  Generic solution to foster market growth.  

- Question about where this work fits in 802.  802.1?  In a legacy thinking of 802 it was out of scope.  Higher level protocol in terms of 802.  2.5, not even 3.  Trying to establish a link.  

- Juan Carlos re inter-functionality, regular networks have interfaces for terminals that have multiple interfaces.  Could have certain high-level functionality across interfaces.  

- Bernard asked re IEEE service provisioning doc, should IETF have sent that doc to the OmniRAN group for comment.  If getting something established or agreement, but OmniRAN is still trying to define a charter.  Any suggestions/guidance from IETF welcome.  In IETF terms, it is pre-charter.

- Have 5 interfaces to consider.  Heterogeneous networking means different technologies.  What OmniRAN would provide to 3GPP core, SaMOG defining a gateway conreolling the trusted non-3gpp access network by the IPC. 

- No desire to reinvent the wheel, limit the effort to create beneficial results.  Plenty of protocols available for OmniRAN to leverage, e.g. IETF, WiMAC, WiFi Alliance, Zigbee.  Leading to the main goal of the stud group. OmniRAN EC SG is searching for the single most wanted access network function to be specified for IEEE 802.

- Question of what has to be specified in the first step.

- Which entry points should OmniRAN use into the IETF, how to start discussions?

- Spencer said the IETF needs to think about which Areas before which WGs.  Looks like it would be in several areas, inc. TSV.  The thing about 3GPP, was this intended as a separate conversations with 3GPP an IETF?  Seems likes if you have IETF people in the room, likely to hear "but you can do this with IP."  Bilateral discussions.

- Max replied it's a pre-charter discussion in a tough time frame.  Would take too much time to get everyone together, looking for entry points for peer-to-peer discussions.

- Lars noted that this is looking like with 3GPP which caused a lot of work for IETF, which makes him nervous.

- Max said the foundation for the work is the WiMAX specification.  The specs were completed.  The effort is manageable.  Don't have the full-time professionals as in WiMAX [?].  No specification about how someone should roll out a network based on IEEE 802 technology, and that's causing some trouble now.  

- Juan Carlos: Making prioritization of the use cases received, requirements that have to be solved first.  Functionality in the future.  

- Spencer: Each org provides a heads-up at the organization level, not needing to figure out which WG, because with a topic like this you're likely to miss something.

- Ross: IETF has a lot of groups, and it seems like most successful when  a charter is clearly defined and you figure out how the pieces fit together, and I haven't figured out what is here.  Max replied that that is true, still working to figure it out.

- Ted: How does this relate to 802.21?

- Max: .21 is in the int layer.  We also have 802.ix where it also fits.  We have pieces, and getting something together that complements the pieces we already have.



1:45-2:15PM - Time Protocols Unification - 802.1AS/1588 and NTP (Michael Johas Teener)
http://www.iab.org/wp-content/IAB-uploads/2013/01/as-mjt-time-synch-unification-for-IETF-and-1588-0313.pdf

- Telecom real-time control stuff.  NTP and IEEE 1588-2008 and 802.1AS-2011.  But are not done yet.  

- Stewart mentioned the 1588 design committee and noted they tried to align it with as much of the IP model as possible.  Having trouble without he cartoon version of this presentation not representing the real version.

- Michael: Lots of unfortunate compromises.

- IEEE side proposed new 802.1AS work,  the layer 2 service that provides the timing.  Info necessary to provide higher layers.

- Propose that IETF work bridging between NTP and 1588.

- Michael's opinion that 1588v3 should deprecate TCs, and 802.1AS and 1588v3 should be merged and repartitioned, and IETF should take over router-to-router service
 
- Eric not sure we want to take transparent clock out of 1588.  An abstract model for TC behavior needs to be defined in 1588.

- Good news is this is one example of where the overlap is working right: 1588 will work with 802.1AS.  Means that Michael is proposing a re-partition of the work in AS.

- Brian asked if the PAR was 1588v3; was told "no" in the TICTOC meeting, it was v2 extensions.  Michael said it was to be determined by the study group who write the PAR.  

- Rather simplify than proliferate.

- Setting up system to allow multiple paths throughout the subnet for different types of data--or same types of data for more redundancy.  

- Brian notes that we have discussed a liaison relationship between TICTOC and 1588 so the timing issues can be discussed.  Doug Arnold (vice chair od the SG) has proposal on how to carry 1588 time over IP.  If you take time at layer 2, you still have delays in L2 to L4 that can't be accounted for.

- Stewart observes that the conversation is getting to technical for the high-level management meeting here; need to get the right people in the room together, which the liaison should help with.

- Dan suggests a small design team to work on this.

- Roger notes that 1588 is not a part of 802.


2:15-3:00PM - Dealing with Regulators (Mike Lynch)
http://www.iab.org/wp-content/IAB-uploads/2013/01/18-13-0033-00-0000-IEEEE-802-in-the-Regulatory-Space.pptx

- Regulatory space different from standards space.  Nothing as unsettling to business people as regulatory uncertainty.

New agenda item: Dual Use Registries (Sean Turner)
http://www.iab.org/wp-content/IAB-uploads/2013/01/dualuseregistries.pptx

- Sean: Actually mean multi-use registries.  IETF uses IANA.  What happens when more than one camp want to use the same registry.  

- Looking for a way to decouple the registries later.  Need to identify registries that are dial use, set up new registries, and point IEEE spec at those registries.  Not sure if the IKEv1 issue is an isolated case or not.

- Bernard noted that another example came up in RADEXT this week.  Why not create entry in e IANA registry and point it at the RAC.  So it does come up.

- Russ asked if the IETF would a reason code added that would affect the RADEXT side.  If that's the case, then separate registries would be better.

- The registry was created by an RFC, and IANA has it.  RFCs adding number to the registry, then IEEE wanted to add values to the registry.  Would have been bad if the RFCs that use the registry on the IETF side point to the IEEE specs.

- Whether there are IEEE standards that use the registries; the people in the room can only speak to 802.

- Dave pointed out OUIs are a dual-use registries.  Also ethertypes.

- Eliot: Is this a problem where the original RFCs didn't properly handle unknown values?  [No.]  

- Sean: Concern is that IKEv1 was deprecated by registry was not.

- Eliot: Each registry has a policy; don't have a single hard rule for all registries.  Some have a small number of bits so we need to be more strict.  Others we allow anyone to ask for a number.  Should stick to the policy we set for that registry.

- Pete: We have registries that have a column that say "suitable for this use."  If you share one of those registries, and we define something that is goofy for that use, then it has no business being in that registry, and the policy should make that clear.  But problem is that we don't anticipate people putting things in other than for intended.  Looking for sanity check for use other than the intended use.

- Bernard: Original reason for referencing IKEv1?  They just liked the list of crypto-suites.

- The IETF and IEEE registration authorities should have harmonized procedures on how they deal with these issues, because we have the same set of problems.  

- Dorothy clarified that in this particular instance, the RAC would not have been involved, it would have been the 802.11 [].  Not an IEEE-level issue.  The existing IETF processes for dealing with the IANA worked.  The characteristic of modification of registries where difference levels of authorization needed (expert review, RFC required, etc) worked.  This has raised awareness that this sort of situation can occur, so we can be more vigilant in the future about if we are referencing IETF registries.  We can certainly do that in the future.

- Jari noted it is okay to reference in other bodies, but you need to think about what you're really doing.  If I'm going to sue that, then I'm forever bound whatever you guys are going to do in that space.  The IETF is going through its own set of rules within IANA for allocating things, and we're publishing RFCs where things are not well defined.

- Pat said that IEEE 802 and IETF work differently in terms of registries.  When IETF creates a number space, it is turned over to IANA who does the assignments.  In 802 if there is number space that is used across standards, it might get turned over to the RAC.  But often the number space is left within the standard.  

- Bernard asked if there was need for ongoing cooperation here.  Handled by IESG on case-by-case basis?  Sean said that is how it was done, but it was more painful than it needed to be.

- Jari said the ongoing effort by IANA to clean things up has been helpful.  But some guidance on when it is okay to reference a number space would be useful.

- With 802 standards there is a specific point when registry info is put in; have time to evaluate whether it's appropriate to be in there and then 6 months to a year from then until publication date.

- Identify areas of conflict before going to sponsor ballot; can change 802 process next week. [Agreement that would be good]


3:00 - 3:15PM coffee break



3:15-4PM - action items and planning work ahead 

- For the next cycle as new ADs transitioned, will have 2 teleconferences between now and July (end of April--29 April or 2 May, and mid-June).

ACTIONS

- Brian to take action to get together with Michael to form a small design team to clarify the issues going on in the study group on Time Protocols Unification.

- Spencer to add text to 4441rev re dual-use registries.

- 802 EC to change order in which registry info is added to 802 docs to allow more time to deal with dual-use registry issues.

- Figure out offline the teleconference schedule (29 April or 2 May, and mid-June).