Subject: [tsvwg] Fwd: Confirmation for Auto-Post of I-D draft-shepherd-multicast-udp-guidelines

From: Greg Shepherd <[email-masked]>
Date: Thu, 13 Jun 2013 08:29:26 -0700

I'd like an agenda slot in Berlin to discuss this work.

Thanks,
Greg

---------- Forwarded message ----------
From: IETF I-D Submission Tool <[email-masked]>
Date: Wed, Jun 12, 2013 at 10:30 AM
Subject: Confirmation for Auto-Post of I-D
draft-shepherd-multicast-udp-guidelines
To: Greg Shepherd <[email-masked]>

Hi,

The IETF datatracker draft submission service has received your draft
draft-shepherd-multicast-udp-guidelines-01, and requires a
confirmation step in order to be able to complete the posting of
the draft.

Please follow this link to the page where you can confirm the posting:
Confirmation URL:
http://datatracker.ietf.org/submit/status/51145/confirm/1b4e70f5499fef25c2d9d6c7990b8e06df9c81b8/

Best regards,

        The IETF Secretariat
        through the draft submission service

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 13 Jun 2013 15:49:13 +0000

Hi Greg,

> I'd like an agenda slot in Berlin to discuss this work.

I'm generally in favor of this ID, because it fills an obvious void left by RFC5405.

I'd be curious to know why Section 2.1.4 doesn't follow the guidelines for picking an MTU given in Section 3.2 of RFC5405 and instead always recommends 1280 bytes?

Lars

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 13 Jun 2013 09:17:20 -0700

On Thu, Jun 13, 2013 at 8:49 AM, Eggert, Lars <[email-masked]> wrote:

> I'd be curious to know why Section 2.1.4 doesn't follow the guidelines for
> picking an MTU given in Section 3.2 of RFC5405 and instead always
> recommends 1280 bytes?

Okay, solid point. I could just mirror the text there for IPv4 and IPv6. I
chose the latter as an overall guideline, but since this is the fall-back
condition when all above recommendations are unavailable, the RFC5405
approach is better.

Thanks,
Greg