Subject: [Mip6] Re: [issue66] Setting up forwarding for IPv4 HoA

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 23 Oct 2006 10:06:24 -0700

I object.

I still think we shouldn't talk about a binding
cache entry for the IPv4 home address. how its
implemented is not the issue here. the issue is
about what we are calling it in the DS-MIPv6
specification.

I don't think we had consensus on the mailing
list to reject the issue. did we?

Vijay

Hesham Soliman wrote:
> Hesham Soliman <[email-masked]> added the comment:
> 
> Several IETF specifications describe conceptual data as part of
> documenting a protocol. This is typically done for additional
> clarification. Examples of such specifications include IPsec, ND, and
> MIP (v4 and v6). MIPv6 described the binding cache as a mechanism for
> storing bindings. However, this does not in anyway force implementers to
> implement MIPv6 exactly as described in the document, as long as the
> external behaviour is consistent with the specification. Since this
> specification is an extension to MIPv6, it is appropriate to describe
> the conceptual data structure in a manner consistent with RFC 3775. 
> 
> RFC 3775 maintains that there is a separate Binding Cache entry for each
> home address. As we are extending MIPv6 to support another address
> family (IPv4), we still maintain the same philosophy of one binding
> cache entry per home address, regardless of the type of HoA. 
> Similar to MIPv6, this does not require implementers to do it exactly in
> this manner, hence the term "conceptual data structure". One may choose
> to implement the v4 entry in the routing table for instance (the same
> can be said for the v6 entry). But in all cases, the entries will need
> to be maintained (refreshed/deleted ...etc) as per the BU. 
> 
> Conclusion:
> -----------
> 
> Keeping with the conceptual data structures in MIPv6 makes the spec
> clear and does not limit implementers. There is no harm or bugs
> introduced by the current text. Therefore the issue should be rejected.
> 
> ----------
> status: Pending -> Rejected
> 
> _________________________________________________
> Mip6 issue tracker <[email-masked]>
> <http://www.mip4.org/issues/tracker/mip6/issue66>
> _________________________________________________

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 23 Oct 2006 21:21:24 -0700

> about what we are calling it in the DS-MIPv6

=> DSMIP does what RFC 3775 and many other specs do in IETF. If you have
an issue with that please explain it. 

 > list to reject the issue. did we?

=> When an issue is raised, and no one supports it then we don't have
concensus to do anything. I suggested a rejection, there were no
comments, so I went along with that. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Oct 2006 10:06:53 -0700

> an issue with that please explain it. 

please lookup the earlier mails on why there is an
issue in the first place. you should still have
the mip6trans emails.

for your benefit I am repeating them here.

- in the DS-MIPv6 case, there is only BCE that is
based on the MN's IPv6 home address. all other
information is tied to this BCE. this may include
tunnel state for the MN, forwarding state for an
IPv6 NEMO prefix, forwarding state for the MN's
IPv4 home address, forwarding state for the MN's
IPv4 NEMO prefix.

- we setup binding cache entries for the IPv4 home
address only in MIPv4.

- we shouldn't mix up things by saying we create
binding cache entries for both the IPv4 and IPv6
HoAs.

also see the comments at
http://www.mip4.org/issues/tracker/mip6/issue66

> comments, so I went along with that. 

:) you want people to repeat things all the time.
I count at least two now, Pascal (see the URL above)

for one there was never a consensus to call it a
binding cache entry for the IPv4 HoA. the issue
was open from the beginning. when we picked a draft
to be the base document, it does not mean everything
that is in there in the draft is already agreed to.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Oct 2006 10:06:53 -0700

also see the comments at

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 24 Oct 2006 11:27:04 -0700

> for your benefit I am repeating them here.

=> I'm quite sure most people on this list are not psychic. Since no one
saw the DT mailing list except the DT members, you do need to explain
things for the benefit of the WG...

 > information is tied to this BCE. 

=> Are you saying this is how it should be? I assume you mean you'll
implement it this way. I hope you're not suggesting we mandate that in
the spec. In the current draft (yet to be announced) *nothing* is
mandated as far as the BC is concerned. And nothing should be mandated
as far as the implementation is concerned.

 > - we setup binding cache entries for the IPv4 home

=> Huh? Of course that's the case when only MIPv4 manages mobility for
IPv4 addresses. 

 > binding cache entries for both the IPv4 and IPv6

=> Why not? What conceptual data structure are you suggesting ? 

 > :) you want people to repeat things all the time.

=> No, only once to the WG who's supposed to know what the issue is
about...

 > that is in there in the draft is already agreed to.

=> No one said everything in the draft must be accepted by the WG, not
to my knowledge anyway.

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Oct 2006 11:35:50 -0700

> things for the benefit of the WG...

ok. but as an editor you are supposed to present
all the arguments related to the issue and then
ask for consensus on the mailing list. not present
it in a way such that it is easy to reject the
issue. that is not correct.

>  > information is tied to this BCE. 

you didnt respond to my first point.

> as far as the implementation is concerned.

you are not responding to my email. you are
saying something very generic. I agree that no
implementation specific stuff should be mandated
in the spec. as I said in one of my earlier mails,
this issue is not about how to implement it, it
is about what to call it.

> => Why not? What conceptual data structure are you suggesting ? 

no conceptual data structure at all. the forwarding
state for the IPv4 home address should be tied to
the BCE for the IPv6 home address. this may translate
into a routing entry for the IPv4 home address, but
it is still tied to the BCE for the IPv6 home address.
the routing state disappears when the BCE for the IPv6
home address is deleted.

> => No one said everything in the draft must be accepted by the WG, not

good. the point was that this has been an issue from
the beginning. so you can't claim that an issue has
been brought up against existing text and then suggest
rejecting it on the mailing list. you need to present
two options.

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 24 Oct 2006 15:59:08 -0700

> issue. that is not correct.

=> I believe I did on every issue where there were multiple opinions
discussed. I'm finding it very difficult to represent the alternative
here because there is no technical implication for the spec. It's an
editorial issue that seems to be a matter of taste.

 > is about what to call it.

=> So why does it matter what to call it? What you're saying amounts to
an editorial change. If that's the case, what's confusing about the
current text? I find it clear because it follows 3775, which is well
understood. I don't understand why we're discussing the "name" of this
storage area when no new name was introduced.

 > the BCE for the IPv6 home address. 

=> You're simply replacing one conceptual representation with another.
What you describe above *is* a conceptual representation where a single
BCE is created and the IPv4 HoA is stored in it. 

   this may translate
 > it is still tied to the BCE for the IPv6 home address.

=> If you read my reponse to Jean Luc Gimault you'll find that I said
that all those entries would be linked whether it's done in a separate
entry or not. 

 > the routing state disappears when the BCE for the IPv6

=> Sure, which will happen in either case. Again I stated that in the
same email I mentioned above.

 > rejecting it on the mailing list. you need to present

=> Of course the two options are represented if the issue text is
included in the same email. I didn't suggest pros and cons for either
option (if that's what you mean) because it's  an editorial matter of
taste which has no technical implications on the spec.

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Oct 2006 16:14:48 -0700

Hesham,

I don't believe we can converge on this issue. this
issue has been open for more than a year and we have
discussed it too many times. I am tired.

if anybody else has an opinion on this, please say
something. :)

Vijay