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

[Christer Holmberg <[e-mail]>]

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.