Subject: Re: [Mip4] [Issue 46] Results of WG last call on draft-ietf-mip4-experimental-messages-00.txt

From: Alpesh <[email-masked]>
Date: Thu, 13 May 2004 17:21:53 -0700

Henrik -

HENRIK: I suggest adding new paragraphs as follows:
	"The value for EXP-NONSKIP-EXT-TYPE should be assigned from the
	numbering space for non-skippable extensions which may appear in
	control messages, and also (with the same number) from the
	numbering space for non-skippable extensions which may appear in
	ICMP router discovery messages.  The value 127 is suggested in
	both cases."
	"The value for EXP-SKIP-EXT-TYPE should be assigned from the
	numbering space for skippable extensions which may appear in
	control messages, and also (with the same number) from the
	numbering space for skippable extensions which may appear in
	ICMP router discovery messages.  The value 255 is suggested in
	both cases."

I don't have a problem in adding these two paragraphs - atleast the
first half of both. The only problem is that we are extending the scope
of this draft beyond mobile ip and defining experimental numbers for ICMP
in this draft. I would like to leave it out of scope of this document, since
we are not defining the structure/usage for experimental ICMPmessage.

Comments?
Alpesh

Henrik Levkowetz wrote:

>Hi Alpesh,
>
>Tuesday 11 May 2004, Alpesh wrote:
>
>
>>attached is the draft with relevant corrections. The multiple spaces
>>were because the draft original is in word format and I had set on
>>alignment. I turned that off.
>>
>>
>
>Yes, that's the usual reason ;-)
>
>
>
>>(Actually have discovered that xml is the
>>best tool and will use it for other drafts).
>>
>>
>
>Applause!
>
>
>
>>I am attaching the draft for your reference. I actually cannot go to the
>>2nd link you have below.
>>
>>
>>
>
>Oops!  I had to change some of those links because of a security issue.
>Here is the relevant one.  There are some stuff in the review which I
>would really like you to fix, so if you could take a look at it...
>
>http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=../../reviews/review-ietf-mip4-experimental-messages-00.txt&comments=HENRIK
>
>
>
>
>>I tried to run the idnits tool from your webpage, but that is giving me
>>error.
>>
>>
>
>You seem to be running on windows; in order to run it there you need to
>have cygwin installed.  I'll make a note of that on the webpage.
>
>
>
>>Please let me know if I need to do anything else or if I should just
>>post it to the WG alias and [email-masked].
>>
>>
>
>It would be great if you could fix the stuff in the review, and if you
>like I can run it through idnits again after that to see that everything
>is fine.  If you *do* have cygwin installed on your windows box, I'd be
>very happy to get feedback on any problems with running idnits, so I
>can fix them.
>
>	Henrik
>
>
>

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 14 May 2004 02:48:00 +0200

Hi Alpesh,

> we are not defining the structure/usage for experimental ICMPmessage.

No, that's not right, as I see it.  The MIP extensions to the Router
Advertisments are defined by 3344, and the numbering space defined for
these are fully within the purview of MIP.  These are managed on IANAs
MIP4 numbers page, nowhere else. This is not a question of new ICMP
messages.

	Henrik

---

From: Alpesh <[email-masked]>
Date: Fri, 14 May 2004 10:12:36 -0700

Henrik -

Okay I went through that and in principle agree that it is open ended
statement and leaves open
the scope that ICMP router discovery (advertisement, typically) can also
be included here.

While I agree that it is meaningful to define a ICMP Router
advertisement skippable extension,
I have doubts about the non-skippable extension. The reason being, if as
a host you receive a non-skippable
extension in ICMP RA (router advertisement) are you supposed to
drop/ignore the whole RA?

This is probably not desired as the FA as an access router will always
add the non-skippable extension - making
it impossible for other (non-mobile hosts) to interpret the RA. (While
the counter argument is that
experimental extensions will be used for experimentation only this
should not be a problem). But if we move
forth from experimentation to standardizing that extension, the above
problem still persists.

Comments?

-a

---

From: Alpesh <[email-masked]>
Date: Thu, 13 May 2004 18:26:36 -0700

Okay, I see your point ..

 The second set consists of those extensions which may appear only
 in ICMP Router Discovery messages [4].  Currently, Mobile IP
 defines the following Types for Extensions appearing in ICMP
 Router Discovery messages:

 Value  Name                                                    Reference
 -----  ------------------------------------------              ---------
     0  One-byte Padding (encoded with no Length nor Data field)[RFC3344]
    16  Mobility Agent Advertisement                            [RFC3344]
    19  Prefix-Lengths                                          [RFC3344]
    24  Challenge Extension                                     [RFC3012]

The question I have then is within the ICMP types, the values are not
partitioned
to be skippable/non-skippable (as we have in MIPv4 number space). Also,
their
interpretation is not defined - what if I cannot skip - just ignore the
whole RA?

Do we want to define that behavior here? I think not. On the other hand,
I am
okay with defining an experimental type to be included in RA.

To that end, I would need to add an additional section in the draft - do
you agree?
That would define the abstract structure of this type.

Only resistance I have is doing a WG last call again. We can still post
it to the WG for
comments before sending it to IESG. Comments?

-a

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 14 May 2004 04:17:46 +0200

Hi Alpesh,

Thursday 13 May 2004, Alpesh wrote:
> The question I have then is within the ICMP types, the values are not partitioned
> to be skippable/non-skippable (as we have in MIPv4 number space). Also, their
> interpretation is not defined - what if I cannot skip - just ignore the whole RA?

First, I'm not aware of anything which says that the skippable/non-skippable
division doesn't apply to MIP extensions in ICMP messages - on the contrary,
the wording in 3344 (second last para. of page 14) seems to be carefully
chosen so as to apply to both registration and ICMP messages.

Second, this (as I see it) does give us a defined interpretation in the
ICMP case, too.

> Do we want to define that behavior here? I think not. On the other hand, I am

I don't think that we're doing any definition of new behaviour, this is
already covered in 3344.

> you agree? That would define the abstract structure of this type.

I was thinking that we would be already covered - these extensions would be
defined identically for the Registration and ICMP case.  If you want to put
in a sentence somewhere to clarify this, in addition to the IANA considerations,
that's fine by me.

> it to the WG for comments before sending it to IESG. Comments?

Sounds fine to me.  I wasn't thinking in terms of a new last call.

	Henrik