RE: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA Considerations
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA Considerations
Hi Acee and Charlie,
The usage (for ICMP messages) is described in section 2.1.3 in the
draft. Section 6.3 refers to section 1.8, in which the following text
appears:
o The second set consists of those extensions which may appear only
in ICMP Router Discovery messages [5]. In this document, the
following Types are defined for Extensions appearing in ICMP
Router Discovery messages:
0 One-byte Padding (encoded with no Length nor Data field)
16 Mobility Agent Advertisement
19 Prefix-Lengths
So it seems there is sufficient reason not to remove it.
BR,
Bob
-----Original Message-----
From: Acee Lindem [mailto:acee at redback.com]
Sent: Wednesday, August 08, 2007 9:49 AM
To: Charles E. Perkins
Cc: mip4 at ietf.org
Subject: Re: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA
Considerations
Hello Charlie,
I'd vote to remote it from the revised draft since, as you pointed
out, this usage is not described in body of the RFC 3344 (or the
revised draft). If there are clients that send this pad byte and need
to be supported, I'd think that could be handled outside the
specification since it was never intended or really specified that
this extension should be used for mobile IP messages. However, I'll
leave this to your wisdom and discretion.
Thanks,
Acee
On Aug 7, 2007, at 5:23 PM, Charles E. Perkins wrote:
>
> Hello Acee,
>
> The first, best answer I can give is that I don't know why
> that padding extension is listed there.
>
> Since it would be for UDP payloads, I don't immediately
> see why it should be needed. I don't remember hearing
> anyone express a need for it. There is not any text in the
> body of the specification describing such an extension.
> I don't remember asking IANA to put it in there, but I did
> not comb through all my emails with IANA to be sure.
> I seem to have some very hazy memory of a discussion
> about whether such a padding extension would be needed,
> but I can't resolve when or where or in what context.
>
> I think the simplest thing would be to just remove it,
> but if there are implementations out there relying on the
> existing of the padding extension, we should respect that.
> If more detail is needed, I could make a diff between each
> previous version of the Internet Drafts of the specification,
> but I'd prefer to avoid having to do that.
>
> Regards,
> Charlie P.
>
>
>
>
> ext Acee Lindem wrote:
>> Hi Charlie,
>>
>> Why is the type 0 for one-byte pad listed in section 6.3 under the
>> "Extensions for Mobile IP Registrations"?
>> 6.3. Extensions to Mobile IP Registration Messages
>>
>> The Mobile IP messages, specified within this document, and
>> listed in
>> Section 1.8 and Section 6.1, may have extensions. Mobile IP
>> message
>> extensions all share the same number space, even if they are to be
>> applied to different Mobile IP messages. The number space for
>> Mobile
>> IP message extensions is specified within this document.
>> Approval of
>> new extension numbers is subject to Expert Review, and a
>> specification is required [14].
>>
>> Type Name
>> Reference
>> ---- --------------------------------------------
>> ---------
>> 0 One-byte Padding
>> ~~~~~~~~~~~~~~~~~~~~
>> 32 Mobile-Home Authentication 3.5.2
>> 33 Mobile-Foreign Authentication 3.5.3
>> 34 Foreign-Home Authentication 3.5.4
>>
>>
>> Clearly, that is not the intent nor what IANA has reserved:
>>
>> http://www.iana.org/assignments/mobileip-numbers
>>
>> Thanks,
>> Acee
>
--
Mip4 mailing list: Mip4 at ietf.org
Web interface: https://www1.ietf.org/mailman/listinfo/mip4
Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
--
Mip4 mailing list: Mip4 at ietf.org
Web interface: https://www1.ietf.org/mailman/listinfo/mip4
Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.