Start at 9:04 ART Area Review Team (ART-ART) will be started up. APPSAWG WG will be closed BoF and new WG summaries Document overviews: - Path MTU Discovery for RTP (Petit-Hugenin) - - draft-petithuguenin-dispatch-rtp-pmtud - - Discussion of ICE issues - - Advice: do this in ICE, not RTP - - Will not proceed with this document - Web Linking — revision of RFC 5988 (Nottingham) - - draft-nottingham-rfc5988bis - - Discussion of registry handling - - Recommend Alexey to sponsor - - Barry agrees to shepherd, if so - - Continue discussion on dispatch list - Location Parameter for the SIP Reason Header Field (Jesske) - - draft-jesske-dispatch-reason-loc-q850 - - possibly put into SIPCORE (Adam) - - dispatched to SIPCORE - DKIM Key Update (Levine) - - (no draft) - - suggestion: dispatch to new WG (fast path) - - suggestion: dispatch to CURDLE - - Alexey: new WG is OK; can we draft a charter this week? - - Action to Levine: draft a charter ------------ Topic:                  Path MTU Discovery (PMTUD) for RTP/RTCP Presenter:          Marc Petit-Huguenin Draft:                  draft-petithuguenin-dispatch-rtp-pmtud-00   What is it?   -          Defines the usage of the for RTP/RTCP path discovery using the PMTUD protocol.   Presentation in a nutshell?   -          The following questions/issues were presented:   -          How to uniquely identify RTP/RTCP packets? -          How to signal support/usage of the mechanism in SDP? -          What are the ICE impacts?   What did people say?   -          Most of the discussion was about why ICE can't be used instead.   Ok, so what next?   -          Figure out how to do this on the ICE layer rather than on the RTP layer. Then, IF there are use-cases where RTP would be more feasible they can be looked at. However, currently no such use-cases have been identified.     Topic:                  Web Linking Presenter:          Mark Nottingham Draft:                  draft-nottingham-rfc5988bis-04   What is it?   -          A way to indicate the relationships between resources on the Web and the type of those relationships.   Presentation in a nutshell?   -          The presenter indicated that there are currently no open issues in the draft, but that some minor stuff still has to be done, related to references, terminology, incorporation of errata, ABNF, etc...   What did people say?   -          Most of the discussion was of administrative nature. Is a bis needed, and/or shall the registry be updated (not covered in the current draft). -          It was indicated that a registry change would require a BoF, as it is outside the current scope of the ART area. -          It was discussed whether the specification would be progressed as AD sponsored, or whether a new WG would be needed. People didn't seem to think a new WG would be necessary.   Ok, so what next?   -          Discussions regarding where the work would take place will take place on the DISPATCH list.     Topic:                  Location Parameter for the SIP Reason Header Field Presenter:          Roland Jesske Draft:                  draft-jesske-dispatch-reason-loc-q850-00.txt   What is it?   -          Adds a location value parameter to the Reason header field reason-extension parameter, so that the location value can be interworked from the PSTN.   Presentation in a nutshell?   -          The use-case where the new information would be needed was presented.   What did people say?   -          There was a question whether the Reason header field in an non-200 SIP response would traverse proxies. Indicated that Reason header fields do tend to traverse proxies. -          It was indicated that the work would fit the SIPCORE WG charter.   Ok, so what next?   -          The draft will be dispatched to the SIPCORE WG. SIPCORE will then decide whether to adopt the draft.     Topic:                  Cryptographic Update to DKIM Presenter:          John Levine Draft:                  draft-levine-dcrup-dkim-crypto-00   What is it?   -          Adds a new DKIM algorithm (ECHD), which has a shorter key size than RSA for similar level of security. -          Adds the possibility to store the key hash, rather than the key, in DNS, and include the key in the signature.   Presentation in a nutshell?   -          Deployed DNS configuration software places a limit on key sizes, because the software only handles a single 256 octet string in a single TXT record, and RSA keys longer than 1024 bits don't fit in 256 octets.   -          Two alternatives were presented:  -      1. Define usage of a new algorithm, with smaller keys. -      2. Put a fixed size key hash (instead of the key itself) in the DNS, and put the associated public key in the signature.   What did people say?   -          There was a preference for placing the key hash in the DNS. Then, if people in addition also want to update the algorithm, that can be done too. -          It was indicated that there are IPR(s) associated with publishing a key hash in DNS. -          It was discussed where the work would be done. The CURDLE WG was suggested. It was indicated that the CURDLE WG is very narrowly scoped, and that a new WG would be preferred.   Ok, so what next?   -          A short proposed charter for a mini WG will be written, sent on the list, and the ADs will decided what can be done and where. ------------------------------------