Subject: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01

From: <[email-masked]>
Date: Wed, 2 Dec 2009 21:53:24 +0100

Below are my review comments for the I-D: draft-ietf-mext-binary-ts-01

1. s/If more than one contiguous source addresses need to be mached/If
   more than one contiguous source address needs to be matched

2. s/SPI values need to be mached/SPI values need to be matched

3. W.r.t the ports, does it make sense to have a wildcard flag which
   implies that no part matching needs to be done by the HA?
   The same might apply for the destination address field as well.

4. s/mached/matched in multiple places in the I-D

5. s/concenrs/concerns

One other suggestion:

- The I-D is proposing traffic selectors which are specified in binary
  format. In the future we could have other formats as well for
  TS. Hence the title of the I-D should be "Binary format Traffic
  Selectors for Flow Bindings"

Summary:
--------

I think the I-D does not have any major issues and ready to be
progressed.

-Basavaraj

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 2 Dec 2009 14:00:35 -0800

[email-masked] wrote: 
> [...]

I understand that if neither the start nor the end port fields are included, the traffic selector matches any port number. Same with goes with addresses (or SPIs, etc.).

>   Selectors for Flow Bindings"

Everything in Mobile IPv6 is binary formatted so far, so I don't think we need to outline that in the name of the mechanism. We could entitle it "Simple Traffic Selector Format for Flow Bindings", however =)
 
> I think the I-D does not have any major issues and ready to be

Good. Thanks for the review Raj!

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Dec 2009 15:08:52 -0800 (PST)

----- Original Message ----
> From: "Laganier, Julien" <[email-masked]>
> To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wed, December 2, 2009 4:00:35 PM
> Subject: Re: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01
> 
> I understand that if neither the start nor the end port fields are included, the 
> traffic selector matches any port number. Same with goes with addresses (or 
> SPIs, etc.).
> 
> > One other suggestion:
> > 
> Everything in Mobile IPv6 is binary formatted so far, so I don't think we need 
> to outline that in the name of the mechanism. We could entitle it "Simple 
> Traffic Selector Format for Flow Bindings", however =)
> 
I agree that binary is too generic.

My suggestion is
Traffic Selectors for Flow Bindings Based on IP and Transport Header Fields

What do you think?

--behcet

---

From: "Yuri Ismailov" <[email-masked]>
Date: Thu, 3 Dec 2009 10:04:35 +0100

Hi,
Quick comment about draft title.
The word "simple" does not have any strict technical definition and does
not give any estimate about boundaries of simplicity.
I suggest not using "simple" in the draft name.

/yuri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Laganier, Julien
Sent: Wednesday, December 02, 2009 11:01 PM
To: [email-masked]; [email-masked]
Subject: Re: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01

>    The same might apply for the destination address field as well.

I understand that if neither the start nor the end port fields are
included, the traffic selector matches any port number. Same with goes
with addresses (or SPIs, etc.).

>   Selectors for Flow Bindings"

Everything in Mobile IPv6 is binary formatted so far, so I don't think
we need to outline that in the name of the mechanism. We could entitle
it "Simple Traffic Selector Format for Flow Bindings", however =)

--julien
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 15 Dec 2009 11:36:10 +0000

Hi Raj,

I incorporated your comments, thanks

Wildcards, as indicated by Julian, are indeed implemented by the
absence of fields i.e., if no start/stop source address fields are
indicated then "any" source address will match.

IMO the title of the document does not need to be qualified with
"Binary". "Simple" or otherwise since these are the first and only
traffic selectors for now. The next type of TS that will be defined
can qualify itself to differentiate with these.

Regards
George

---

From: <[email-masked]>
Date: Tue, 15 Dec 2009 16:47:19 +0100

Thanks for addressing the comments George. I am okay with your proposed
response to the issues I had mentioned.

-Raj