[MEXT] Next steps with draft-ietf-mext-flow-binding

[Jari Arkko <[e-mail]>]

This draft was discussed in yesterday's IESG call. It is not yet 
approved, because there is one pending Discuss from Lars Eggert (see 
below). Please address it as follows:

>   DISCUSS-DISCUSS: There have been several revisions since Allison
>   Mankin's tsv-dir review, but it's unclear if the issues she raises
>   have resulted in text changes or where otherwise dealt with (there was
>   no follow-up email to the review.) Please clarify?
>   

I promised Lars that we'd send him a summary of the responses and 
changes. Please do so.

> Section 4.2., paragraph 11:
> >          This is an 8-bit unsigned priority field to indicate the
> >          priority of a particular option.
> ...
> >          FID-PRI MUST be unique to each of the flows
> >          pertaining to a given MN.  In other words, two FIDs MUST NOT be
> >          associated with the same FID-PRI value
>
>   DISCUSS: I may be misunderstanding this, but if FID-PRI must be unique
>   for all flows of an MN, and it's 8-bit, then there can only be 256
>   flows? That's awfully little.
>   

If this is true, that's worrisome. Can we expand the field or do 
something else to avoid limiting ourselves to 256 flows? 256 flows is 
quite little in the face of Ajax and so on...

> Section 4.2., paragraph 15:
> >             1 'Discard'.  This value indicates a request to discard all
> >             packets in the flow described by the option.  No BIDs are
> >             associated with this Action.  Care should be taken when
> >             using this Action as it will lead to disrupting applications
> >             communication.  Implementations may consider notifying
> >             impacted applications in mobile nodes.
>
>   DISCUSS: This action is turning MIP into a firewall control protocol.
>   

I'm not as worried about that as Lars is, but I also would suggest 
removing this part.

> Section 4.2.1.4., paragraph 13:
> >       A variable length field, the format and content of which is out of
> >       scope for this specification.  The traffic selector defined in
> >       [I-D.ietf-mext-binary-ts] is mandatory to implement.
>
>   DISCUSS: If it's mandatory to implement, then it needs to become a
>   normative reference (make this clear by s/mandatory to implement/MUST
>   be implemented/). I also don't understand what the purpose of this
>   specification is if this critical piece is left undefined? It can't
>   really be used without this, can it?
>   

I agree that the reference must be normative.

I am expecting a new revision and an e-mail detailing what we did based 
on Allison's review.

Jari