Subject: Re: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-00.txt

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 25 Feb 2008 03:58:00 +1000

I've updated the draft with your comment, a couple of responses below
though.

 > 
 >      - Page 8, 1st paragraph - It says "If this option is not  
 > including..." yet
 >        it said previously that the option "MUST" be included.  
 > Perhaps, the "MUST"
 >        should have been a "MAY".

=> No I think the MUST is correct. The rest of the sentence explains why the
option would not be included despite the "MUST".

 > 
 >      - Page 9, second paragraph - Replace "to the IPv4 care-of  
 > address." with
 >        "in an IPv4 header specifying the IPv4 care-of 
 > address as the  
 > destination."

=> I replaced it with " to the IPv4 care-of address, which was included in
the source address of the IPv4 header encapsulating the binding update".

 >      - Page 11, IPv4 home address - It says "should be defended by  
 > the home agent". This
 >        terminology is usually associated for IPv6 Duplicate Address  
 > Detection. What
 >        does it mean for IPv4?

=> It's the same thing that an IPv4 HA does, I don't see anything specific
to v6.

 > 
 >      - Page 20, 4th bullet - It says "mobile node MAY include the  
 > IPv4 home...". Yet in
 >        section 2.3.1 on the top of page 8, it says 
 > "therefore SHOULD  
 > NOT include the
 >        option...".

=> Yes for a completely different reason. In page 8 it talks about a missing
option, in page 20 it talks about a present option that indicates an error
in allocation.

 >      - Page 26, IANA Assignments - Should there be a new 
 > registry for  
 > TLV-Header
 >        encapsulations types?

=> Sadly yes but I think it needs IETF concensus.

Thanks for your comments,
Hesham

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 25 Feb 2008 16:08:59 -0500

Hi Hesham,

> option would not be included despite the "MUST".

Specifying "MUST" and providing backward compatibility usually don't  
go together.  So, when you say:

    In addition, if the binding update included an IPv4 home address  
option,
    the binding acknowledgement MUST include the IPv4 address
    acknowledgment option as described later in this specification.

It is contradictory to define the action when it is not specified.

    If this option is not included in the binding
    acknowledgement and the IPv4 home address option was included in the
    binding update, the mobile node MUST assume that the home agent does
    not support the IPv4 home address option and therefore SHOULD NOT
    include the option in future binding updates to that home agent
    address.

But I guess you understood my comment but disagree with the logic. I  
think people will be able to figure it either way but that "MAY" is  
more correct.

> the source address of the IPv4 header encapsulating the binding  

Ok.

> => It's the same thing that an IPv4 HA does, I don't see anything  

You'll note that RFC 3344 doesn't refer to defending the IPv4 home  
address on the home link. My point is that the term "defending" is  
usually associated with MIP6 and IPv6 DAD on the home link.

> option, in page 20 it talks about a present option that indicates  

Right - I agree. This is the situation where the IPv4 allocation  
fails - not where it isn't supported. Sorry for the confusion.

> => Sadly yes but I think it needs IETF concensus.

That's fine. But if this is an independent number space, it should  
have its own registry.

Thanks,
Acee

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 27 Feb 2008 10:04:00 +1000

though.

Specifying "MUST" and providing backward compatibility usually don't go
together. So, when you say: 
In addition, if the binding update included an IPv4 home address option,
the binding acknowledgement MUST include the IPv4 address
acknowledgment option as described later in this specification.

But I guess you understood my comment but disagree with the logic. I think
people will be able to figure it either way but that "MAY" is more  
 correct.  
 
=> Yes I understand your concern but a "MAY" is the wrong way to go because
the option has to be acknowledged. So there are two ways to do this, either
we say that the HA MUST support the option and ignore that a bug could cause
the HA to not send the option, or we keep the text as is. I think the
current text is ultra conservative and covers the MN's actions in case the
HA contained a bug that made it not send the option. I don't see any harm in
this. 

You'll note that RFC 3344 doesn't refer to defending the IPv4 home address
on the home link. My point is that the term "defending" is usually
associated with MIP6 and IPv6 DAD on the home link.  
 
=> I guess I see it as an english word. The HA in 3344 defends the address
in the same way it does in v6. The word defend is just a word that is not
tied to v6. 

registry for 
TLV-Header
encapsulations types?

That's fine. But if this is an independent number space, it should have its
own registry.

= > It's in the latest draft.
 
Hesham 

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 27 Feb 2008 09:18:46 -0500

Hi Hesham,

Sounds good.  See one suggestion below.

On Feb 26, 2008, at 7:04 PM, Hesham Soliman wrote:

> Specifying "MUST" and providing backward compatibility usually  
> don't go together. So, when you say:
> But I guess you understood my comment but disagree with the logic.  
> I think people will be able to figure it either way but that "MAY"  
> is more
>  correct.
>
> => Yes I understand your concern but a "MAY" is the wrong way to go  
> because the option has to be acknowledged. So there are two ways to  
> do this, either we say that the HA MUST support the option and  
> ignore that a bug could cause the HA to not send the option, or we  
> keep the text as is. I think the current text is ultra conservative  
> and covers the MN's actions in case the HA contained a bug that  
> made it not send the option. I don't see any harm in this.

If you make another update after the AD review, I would explicitly  
differentiate between the backward compatibility case and the dual- 
stack case. In other words, replace "the home agent MUST" with "a  
home agent supporting this specification MUST".

Thanks,
Acee

> => I guess I see it as an english word. The HA in 3344 defends the  
> address in the same way it does in v6. The word defend is just a  
> word that is not tied to v6.
>
>

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

---

From: "Robert J Marks" <[email-masked]>
Date: Wed, 27 Feb 2008 09:17:13 -0600

Hi Acee,

Perhaps this is a minor point, but I do not agree with your suggested
wording.

Any draft's requirements apply only to entities supporting that draft. A
draft cannot place requirements on an entity that does not support the
draft. So all MUST requirements in a draft, by definition, can be assumed to
be read as " An entity supporting this draft MUST.."

Perhaps a better place to note the problem and MN action is in section 4.4,
in the bullet on page 20 dealing with absence of an IPv4 address
acknowledgement option when the IPv4 home address option was present in the
binding update. Perhaps the following blue text should be added:

   - If no IPv4 address acknowledgement option were present, and an
     IPv4 home address option was present in the binding update, the
     mobile node MUST only create one binding update list entry for its
     IPv6 home address.  The mobile node MUST assume that the home agent
     does not support the IPv4 home address option and therefore SHOULD
     NOT include the option in future binding updates to that home agent
     address.  The mobile node MAY include the IPv4 home address option
     in future binding updates to other home agents.

Bob

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Wednesday, February 27, 2008 8:19 AM
To: Hesham Soliman
Cc: [email-masked]
Subject: Re: [MEXT] ID ACTION:draft-ietf-mext-nemo-v4traversal-00.txt

Hi Hesham, 

though.

including..." yet

Perhaps, the "MUST"

address.

correct. 

If you make another update after the AD review, I would explicitly
differentiate between the backward compatibility case and the dual-stack
case. In other words, replace "the home agent MUST" with "a home agent
supporting this specification MUST". 

Thanks,

Acee 

 

the home agent". This

Detection. What

does it mean for IPv4?

to v6.

 

registry for 

TLV-Header

encapsulations types?

Hesham 

Thanks,

Acee

 

Hesham

---

From: Acee Lindem <[email-masked]>
Date: Wed, 27 Feb 2008 13:41:26 -0500

Hi Robert,
I'd agree if this were a completely new protocol. However, it is an  
OPTIONAL enhancement on top of the existing Mobile IPv6 protocol and,  
as such, must address backward compatibility for the BAs from HAs not  
supporting the specification. The text you suggest would also help  
clarify this.

Acee

On Feb 27, 2008, at 10:17 AM, Robert J Marks wrote:

> Hi Acee,
>
> Perhaps this is a minor point, but I do not agree with your  
> suggested wording.
>
> Any draft’s requirements apply only to entities supporting that  
> draft. A draft cannot place requirements on an entity that does not  
> support the draft. So all MUST requirements in a draft, by  
> definition, can be assumed to be read as “ An entity supporting  
> this draft MUST….”
>
> Perhaps a better place to note the problem and MN action is in  
> section 4.4, in the bullet on page 20 dealing with absence of an  
> IPv4 address acknowledgement option when the IPv4 home address  
> option was present in the binding update. Perhaps the following  
> blue text should be added:
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Acee Lindem
>> => Yes I understand your concern but a "MAY" is the wrong way to  
>> go because the option has to be acknowledged. So there are two  
>> ways to do this, either we say that the HA MUST support the option  
>> and ignore that a bug could cause the HA to not send the option,  
>> or we keep the text as is. I think the current text is ultra  
>> conservative and covers the MN's actions in case the HA contained  
>> a bug that made it not send the option. I don't see any harm in this.
>