Re: [tcpm] New Version Notification for draft-williams-exp-tcp-host-id-opt-00.txt

[Yoshifumi Nishida <[e-mail]>]

Hi Med,

Thanks for the clarification and sorry for slow response.

On Thu, Jan 30, 2014 at 11:34 PM, <[e-mail]> wrote:

>
>
>
> 1: It seems to me that the option format might be too simple to
> accommodate multiple proposals.
>
>     I'm not very sure how the receiver can identify which proposal has
> been used.
>
> *[Med] We have discussed that point among authors and we decided to not
> include a field to indicate what information is carried in the HOST_ID
> field (e.g., IP address, port number, etc.) for following reasons:*
>
> ·         *Cases where only a single identifier is required are more
> common (i.e., the default behavior is to inject some bits of the internal
> IP address in the HOST_ID field). *
>
> ·         *Cases that require multiple identifiers to be included (e.g.,
> source IP address:source port number, or a list of IP addresses) are those
> where the same administrative entity is managing the entity that injects
> the HOST_ID option and the one server that will make use of that option. A
> typical use case is the load-balancing scenario. *
>
> *This point was recorded in the draft: *
>
>
>
> *"Note, there is no need*
>
> *   to signal the semantic of the included data as this specification*
>
> *   assumes the service is aware of that information by out of band means*
>
> *   (e.g. both the service and the address sharing device are managed by*
>
> *   the same administrative entity).*
>
>
>
> *" *
>
> *The beauty of advancing this effort in the experimental track is to
> assess whether these assumptions are valid ones, identify whether there are
> use cases which require a means to explicitly indicate the semantic of the
> included data, etc.*
>

I see...  I felt a bit uneasy for the great flexibility, but we can discuss
this later if this is an important point.


>
>
>
> 2: Section 4 seems to contain similar information on option usages which
> described in other detailed proposals.
>
>     Isn't it a bit redundant? Or, is there any conflicts between the
> usages in the draft and other proposals?
>
> *[Med] One of the goals of this document is to have a unified
> specification that would cover the use cases we have on the table. As such,
> this document is self-contained. An implementor can develop the option
> specified in this draft without reading the other proposals.*
>

My concern is that for example, Section 5 in
draft-wing-nat-reveal-option-03 contains some kind of rules for the option
usage and Section 5 in draft-williams-overlaypath-ip-tcp-rfc-04 also
contains similar ones. If these information is different from what is
described in Section 4 of this draft, I think it will be confusing for
implementers. I think it would be good if other drafts don't have this kind
of info in order to avoid confusions.
I prefer if you can clarify which info should be written in this draft and
which should be written in other companion drafts.

Thanks,
--
Yoshifumi