Re: [dispatch] IETF#98: DISPATCH notes (Christer)

[Mary Barnes <[e-mail]>]

Thanks!

On Wed, Apr 5, 2017 at 12:50 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> Below are my notes from the DISPATCH session.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> -------------------------
>
>
>
> *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.
>
>
>
>
>