...

1. Mark Shostak (AT&T)
2. Pankaj Goyal (AT&T)
3. Kelvin Edmison (Nokia)
4. Al Morton  (AT&T)
5. Karine Sevilla (Orange)
6. Ulrich Kleber (Huawei)
7. Petar Torre (Intel)
8. Michael Fix (AT&T)
9. Tomas Fredberg (Ericsson)
10. Trevor Cooper (Intel)
11. Ahmed El Sawaf ( STC)

Special Notes:

• Each of the three RM sections will get 20 minutes
• Given the limited time available, we will focus on identifying issues/actions/next steps, but not solving them right now
• Weekly RM meetings are intended to
  
  • Identify owners for new Issues
  • Track open Issues
  • Address technical issues that cannot be resolved online (i.e. resolve stalls)

...

• New Business

Actions:

• General
  •  None  None at this time
    
•  Core
  •  None at this time
  •  Oya (w/ Tomas as backup) to schedule meeting series for Generic Fabric Model
  •  Mark to advise Oya and ensure Oya or Tomas get the GFM call scheduled
  •  Issues #1 and #3, potentially to be addressed by Pankaj
  •  Kelvin to refer VNF Evolution issues #4 and #5 to TSC and/or Gov board for strategic/business directive
• Ops
  •  None at this time
• Comp
  •  None at this time

...

• General
  • Reviewed LNF/GSMA anti-trust policy
  • Announced current Lead's (Mark Shostak) retirement, and Co-Lead (Kelvin Edmison) would take over until WSes are reorganized
•  CoreTBD
  • Generic Fabric Model
    • Introduced Generic Fabric Model (GFM) and CNTT Networking initiatives
    • Agreed: Initial GFM objectives, requirements and strategy would be worked out of RM
    • Agreed: If at some point a dedicated GFM workstream is required, it can be created at that time
    • An RM::GFM-specific sub-meeting will be created with scheduling to better accommodate key players
  • VNF Evolution w/ proposal to use VNF Profiles
    • Decomposed VNF Ev. challenge into 5 constituent issues
    • 1 issue closed, 2 issues routed to TSC/Gov for business decision; 2 issues opened in Github Issue #1007 https://github.com/cntt-n/CNTT/issues/1007 (see Actions above)
    • Trevor raised additional point; may be a 6th issue - If a site upgrades h/w, but there is NO coincident increment in phase of VNF Evolution (i.e. h/w upgrade, but remains on same CNTT Rls), is that managed / how is that managed? // may require a site-specific vintage identifier (e.g., Basic w/ variant 2b, where 2 is the Evolution phase (CNTT Rls 2) and b indicates it's an additional resource pool of the same VNF Profile variant, but with different h/w). More investigation is required
• Ops
  • TBD
• Comp
  • TBD