Subject: Draft Agenda for 6MAN for IETF87

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Jul 2013 18:09:45 -0700

The draft agenda for 6MAN is available at:

  http://www.ietf.org/proceedings/87/agenda/agenda-87-6man

We were able to accommodate most requests, but two were included in the "If time permits section", and one rejected.  There may be some changes in times or ordering between now and the 6MAN session.

Please send us corrections.

Presenters should send your slides to the chairs no later than Noon on Sunday July 28.  The session will be covered by Meetecho and the slides must be uploaded in advance of the session.

We need a jabber scribe and minute taker.  Please volunteer.

See you all in Berlin

Thanks,
Bob & Ole

---

From: Glen Turner <[email-masked]>
Date: Wed, 24 Jul 2013 00:19:13 +0930

As I do not attend meetings, perhaps someone at the meeting could ask the author these questions:

1)

> 10 - discard the packet and, regardless of whether or not the
> packet's Destination Address was a multicast address, send an ICMP
> Parameter Problem, Code 2, message to the packet's Source Address,
> pointing to the unrecognized Option Type.

> The PDM destination options extension header SHOULD be turned on by
> each stack on a host node.

Perhaps the Security Considerations section could explain why this "SHOULD" be enabled feature does not give a way to implement a variation of the Smurf attack?

2)

> As with all other destination options extension headers, the PDM is
> for destination nodes only. As specified above, intermediate devices
> MUST neither set nor modify this field.

Does this "MUST" prevent firewalls stripping the PDM option at the site network edge? It seems a rather strong requirement that firewalls cannot do this. Perhaps the intent is that the entire packet be dropped by a firewall if PDM is undesired by the site's administrators?

Maybe the I-D could explain in more detail what an intermediate system like a firewall is permitted to do with a PDM-containing packet entering a zone where PDM is not permitted (drop with Admin Prohibit ICMP, etc).

3)

> Application Reserved
> A 64-bit field reserved for performance and diagnostic metrics to be
> used by end nodes.  The meaning is agreed upon by the source and
> destination nodes.

Usual whinge about vendor-defined fields in specifications which are intended to achieve interoperability. How can we even tell if 64b is adequate? If justification for the adequacy of 64b remains lacking then I counter-propose that 0b is adequate.

Thank you
glen