Matthew Bocci and Dec Wojciech chairing. Matthew presented the status. Slides. Charter modification on the way. Need MIB reviews! Base protocol draft Roberta Maglione =================== Slides. Woj pointed out that we are reusing GSMP protocol values e.g. port number, but declaring ourselves incompatible. Have to make sure there are no issues with this. Question of where PON fits. Tom T expressed view that PON could be in a separate document. Open issue: registry for tech type. We will create one. Question about whether ready for WGLC. Tom T noted that since status-info is defined in base along with the registry of status codes his primary concern regarding the Multicast Status message has been satisfied. On how PON fits in: seems appropriate to use capability mechanism to reflect capability to operate on PON. Again, need to clean up versioning as well as new status message (see below). Multicast Extensions Francois Le Faucheur ==================== Discussion of open items. Issue of whether AN should do delegated bandwidth query. Francois says use case covered by reset procedure. Fortune Huang says reset procedure is too heavy, need something simpler. Francois: send proposal for lighter-weight procedure to mailing list. Re Multicast Status movement to base: Francois and Woj feel idea has merit. Tom Taylor has action to provide alternative text to list for base-level Status message. Anticipate WGLC in the relatively near future after action items complete. Wenhu Lu (Ericsson): would like multicast to cover broadcast. Simpler multicast operation. Tom T and Woj asked that speaker provide suggestions for changes in text he would like to see to the list. Basic feature is automatic replication of streams at the AN. Intention is to avoid Join and Leave. Suggestions that it can already be done. ANCP Migration Thomas Haag ====================== Slides. Review of ANCP development and deployments. Discussion of use of version/subversion fields to cover deployed versions of code. Problem is that one cannot register IANA codepoints based on I-D versions. Have deployment problem. Question for clarification: does he expect existing TLVs to be modified. General agreement that we should never do that. Discussion: chairs: Tom Taylor: tight coupling to documents. New version only for new version of base protocol document. Capability X designates support of specific RFC Y or designated part of it. Concern: new TLVs. Have to ensure they are associated with specific new capability/sub-capability. Base document /IANA registry for capabilities must specify the rules clearly. Thomas: problem was 4 year cycle to develop protocol. Time to market considerations. Noted that putting versioning of type asked for into protocol means deployed code has to be updated anyway. To distinguish RFC version from any previous one already deployed (which at least distinguishes compliant from prior implementations), RFC version needs version/sub-version to be different from anything already deployed. Probably version 3.2 should be OK. Agreement in room to go this way. Pre-RFC version will be 3.1. RFC Editor's note to change version from 3.1 to 3.2 upon publication.