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

["Tsirtsis, George" <[e-mail]>]

Hi Jari/Lars, et.al.,

I just submitted v10 of the draft handling Lars's comments. See inline:

-----Original Message-----
From: Jari Arkko [mailto:[e-mail]] 
Sent: 10 September 2010 05:18
To: [e-mail]; [e-mail]
Cc: IESG; Lars Eggert
Subject: Next steps with draft-ietf-mext-flow-binding

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.

GT> several days ago I forwarded to Lars my response to Alisson's comments but I summarize below. 
- Accepted Alisson's suggestion and now the binary traffic selector draft is referenced and mandated for interop reasons. In the latest version I made it a normative reference based on Lars/Jari's suggestion.
- Alisson suggested that 255 TS types might not be enough but this was discussed in the WG and it was felt that an additional Sub-option Type can be defined at a later time for additional TS types if needed. Remember these are 255 different languages for *defining* a flow. 
- Alisson questioned whether a single FID Summary option is sufficient. Initially I thought that 128 FIDs are plenty. Based on Lars's comments though I changed the FID-PRI to allow for more active FIDs in support of MRs, which meant that I also had to allow multiple FID Summary options for the same reason. 
- The security considerations section was beefed up based on Alisson's and other peoples' comments.
- Alisson also spotted a number of Nits which we fixed 

> 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...

GT> As I said above I extended the field to 16bits, thankfully we have space w/o having to change the structure of the option.


> 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.

GT> I removed this Action, which means that the only Action defined is 'Forward', which is pointless and makes the spec read really strange. Given this I dropped the Action field, turning it into 'reserved' bits. This resulted in some editing which generally simplified a number of explanations.


> 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.

GT> I made it a normative reference. There is a story about why TS formats is outside this draft but I will not bore you with it.

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

GT> I hope this e-mail and the new version satisfies all the comments/suggestions we received.