>>>>> On Tue, 12 Feb 2002 20:16:10 +0100,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
>> - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing
> One of the main decisions in recent revisions of this draft is...
> => so we have to require the definitions somewhere (a rfc2292ter I-D?)
Probably yes. (Particularly) as for mobile IPv6, it will need quite a
lot of new API stuff and I think it is worth a separate draft.
>> - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined...
> Section 6.7 describes how the outgoing interface is chosen.
> => I've missed this forward reference!
Okay, then I'll just add a reference to Section 6.7 in 6.1.
>> - 6.5: are some definitions of well known values useful?
>> (IMHO this is the job of DiffServ WG to answer)
> I'm not sure about this comment. What exactly do you want in this
> section? Are you requiring some revise in this section?
> => examples of a well known value are code points of class selectors
> (but they are not IPv6 specific).
Right, so I'll just keep the current text without mentioning
particular traffic class values.
(but I'll contact itojun, who is the author of the original
draft of this Section, if I miss something here.)
> Please let me make sure about this comment...are you proposing to
> remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper
> position of a destination options header (only with the IPV6_DSTOPTS
> option)?
> => yes
> If so, how can a user specify a couple of destination
> options headers before and after a routing header?
> => he cannot but he doesn't need it and he cannot specify
> a destination option header just before a fragmentation header.
> IPV6_RTHDRDSTOPTS is unnecessary and misleading.
Hmm, I admit that the single IPV6_DSTOPTS would be enough for today's
(even "advanced") applications. So I, for one, can live with the
single option. However, I'm also quite sure this part is
controversial. I'd like to know others opinions...
>> - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex)
> Do you mean the send() message should return an (immediate) error when
> the packet is not fit in the outgoing link MTU? But, as Erik
> explained in his reply to Vlad, we cannot always expect the immediate
> error. I admit the spec is a bit complex, but the spec should be
> generic enough (i.e. we cannot assume a particular type of OSes.)
> => I've read Erik's answer but just try to explain the MTU stuff to
> a common programmer...
So, what do you want in this section? Are you requiring a change
here? If so, please be more specific.
>> - 11.4: there is a discussion about MTUs and extra headers added by
>> the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should
>> not take into account the headers. But this makes it less useful
>> for the programmer... (note: this is just a philosophical question
>> for the 2292ter)
> I understand your concern, but, anyway, the value returned by
> IPV6_PATHMTU is just a hint of the initial MTU. Even if it is too
> big, the application can then adjust the packet size with succeeding
> MTU notification (assuming that it also specifies IPV6_RECVPATHMTU).
> So, I'd propose to clarify that the MTU is an "IP MTU" (in your
> definition above) and can be larger than the actual current path MTU
> when the kernel inserts additional headers. Is it okay with you?
> => there is already a document about this so I don't believe you need
> to modify the 05 draft. This is more a remark for the other document
Okay, thanks.
> (BTW I've found a candidate for the previous point :-).
>> - 11.5: is IPV6_REACHCONF really useful (example)?
> Honestly, I personally do not see a practical usage of this option.
> At least I've never seen an application that uses it. I don't mind to
> remove this, but if any other person wants to keep it, I'll just leave
> the current text as is. The definition has been there since a quite
> old revision of the draft, and it can at least be implemented.
> => I don't believe the "it can at least be implemented" argument is
> enough to keep something (the opposite is :-).
Fair enough. Again, I don't mind to drop this section unless someone
wants to keep it.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
