Minutes IETF98: dispatch
minutes-98-dispatch-01

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.

------------------------------------