> If possible, I'd like to see the next revision of the draft before the
> next IETF meeting in London. So my question is:
>
> does anyone (especially in the authors) try to revise the draft now?
I'd like to see the document finished. But I don't have any cycles
to actually drive the open issues to conclusion.
If folks can agree on text to add/change I can do the editing of the document.
Or I can take on a co-author that will help drive this to conclusion
and also do the edits.
> - Add credits for UDP MTU stuff
> - Move information about mapping from inet6_opt to setsockopt and
> cmsg.
>
> What exactly do these two items mean?
The issue about UDP MTU for DNS servers was brought up
by somebody on this list and there was a separate I-D (expired long time ago)
which had one proposal for this. The document should give due credit to
that individual.
The second one is about the structure of the document.
The inet6_opt routines are described as having to do with ancillary data
and in a separate place it is pointed out that the routines
also apply to the same information in setsockopt. This organization could
be better.
> - Fix Authors address wrt Rich.
>
> It's an editorial issue. (But what is the best "address" for him?)
I don't know what is traditionally done in cases like this
thus any guidance would be quite helpful. If he is listed
as an author we need to say something in the address section.
Alternatively we can list him at the top of the acknowldgement section
e.g. with something like
Previous versions of this document [RFC 2292] was co-authored by
the late Rich Stevens.
> - Specify "change" for TCP especially when there are multiple HBH
> option headers etc.
>
> ??? what does "multiple HBH option headers" mean? The IPv6 spec
> requirs a HBH option header appear only once in a single packet. Is
> this a typo, and should this be "multiple DST option headers"?
I guess the comment is generic - applies indepedently of the type of
repeated extension headers.
Is there really something in RFC 2460 which says that packets with multiple
HBH headers should be dropped?
Being "liberal in what you receive" would hint that it would be good to
accept such packets. But then we need perhaps specify something - or at
least point out the issue - for TCP detecting when the set of extension
headers and their content is different in one segment than the previous
segments.
> - If the home address option passed out in If so
> what address value does it contain?
>
> As I said above, I'd prefer a separate option if we really need to
> pass the home address to applications.
I'd be fine with that approach. This means adding some text to say that
the home address option should not be passed to the application when
the application has specified IPV6_RECVDSTOPTS?, right?
Or do you envision two different mechanisms by which the application can
receive this information?
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
