Subject: [MEXT] AD review of draft-ietf-mext-flow-binding

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Feb 2010 13:59:19 +0200

I have reviewed this specification. It is basically in very good shape,
but I did detect a few small issues. Please correct them so that I can
last call the document:

Mobile nodes supporting this specification MUST use the BID option
format defined in Section 4.1. Mobile nodes MUST also register all
care-of addresses using the updated BID option format, either in the
same BU as any flow identification mobility options using them, or in
earlier BUs.

Can you talk about what the backwards compatibility issues with the
additional PRI field are somewhere? I am assuming that 0 in a reserved
field is ignored, and new nodes will treat PRI 0 as a sign that its an
old format BID option.

When a valid binding update is received, any registered FIDs that are
not explicitly referred to in a flow identification mobility option
or in a flow summary mobility option, MUST be removed from the list
of flow binding entries for the mobile node.

Presumably this only needs to be done if the FIDs are not used by this
Binding Update or any other binding that is currently in effect.

3-250 unassigned and available for allocation based on STD
action

Not an RFC 5226 term. Use "Standards Action" and use a reference.

251-255 reserved for experimental use

Add some language somewhere to discuss what experimental use is
appropriate. You can use RFC 5494 Section 4 as a template for this text.

STD action

Please make all of these Standards Action or IESG Approval. The latter
is needed as a special case to allow judgment calls to allocate for
specific needs. E.g., experimental RFCs.

5) New "Traffic Selector Format" namespace for the Traffic
Selector sub-option. The traffic selector format space is defined
by the TS Format field in Figure 5. The following values are
defined in this specification:

0 Reserved

1-250 unassigned and available for allocation based on STD
action

251-255 reserved for experimental use

Similar to the procedures specified for Mobile IPv6 [RFC3775] number
spaces, future allocations from the new number spaces requires Expert
Review as defined i [RFC5226].

Inconsistency. Is the rule standards action, or expert review?

Missing discussions: the document is silent on MTU considerations of
constructing large filter sets. Please include a new section that talks
about this issue, and provides practical guidance on what types of
binding update messages are still expected to work well in practice.

Jari