-Original Message-
From: Ford,M,Mat,DEN5 FORDM5 R
Sent: 17 March 2003 19:57
To: '[EMAIL PROTECTED]'
Subject: slides
will the slides from today's meeting be made available somewhere?
mat.
IETF IPng
The co-authors' plan is to revise the draft according to the comments in hand
(mainly Pekka's) and offer the revision to the WG chairs as the response to the
WG last call. I also discussed with a few security people yesterday, and I
will ask them to have a look at the revised security
apologies for spamming the list with this query twice. seems i am not
receiving mail to the list - i guess as a result of the 'too many hops'
problem recently announced. i am chasing this internally now.
mat.
-Original Message-
From: Ford,M,Mat,DEN5 FORDM5 R
Sent: 18 March 2003 09:26
The current work items in the wg charter and Margaret's presentation on
document status in the WG meeting shows PPPv6 as one of the items. Could
someone clarify what changes/updates are being considered for IPv6 over PPP
rfc? Are they technical or editorial/clarification of existing text?
I
Bound, Jim wrote:
...
5.2 DNS
DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152]
and [RFC-3363] MAY be supported. Not all nodes will need
to resolve
addresses. Note that RFC 1886 is currently being updated
[RFC-1886-
BIS].
DNS use is a MUST
I've read this document, and I would like to see it accepted as
a WG document and charter item.
Comments on the current text:
Section 3
It is recommended that the application does a getsockopt() prior
calling to setsockopt() call so that it can save the existing
source address preference
I think the above paragraph is unneeded and confuses the issue.
Setting the flags to 0 will restore the system default behavior.
If the app is using multiple values at different times, the behavior
is really up to the app, and the issue is not specific to this
socket option. RFC 2553 etc
From: Erik Nordmark [mailto:[EMAIL PROTECTED]
I think the above paragraph is unneeded and confuses the issue.
Setting the flags to 0 will restore the system default behavior.
If the app is using multiple values at different times, the behavior
is really up to the app, and the issue is
One other thing I forgot is that, since we need to pass flags
to getaddrinfo as well as the TCP/IP stack, there is a need to fit
all the flags (whether there are only prefer or prefer+require flags) into
the flag name space for getaddrinfo.
This has some implication on the number of flags one
A new Request for Comments is now available in online RFC libraries.
RFC 3493
Title: Basic Socket Interface Extensions for IPv6
Author(s): R. Gilligan, S. Thomson, J. Bound, J. McCann,
W. Stevens
Status: Informational
Date:
Agreed. But how can a node find an address without MUST DNS. The point
is that a requirement to use is based on the situation. My point last
night.
/jim
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2003 4:45 PM
To: Bound, Jim
RESEND. I am hearing not all got this for some reason.
/jim
-Original Message-
From: Bound, Jim
Sent: Tuesday, March 18, 2003 2:08 PM
To: '[EMAIL PROTECTED]'
Subject: Nodes Requirements Input
WG,
For any show of hands for Thursday a.m. per any discussion of Node
Requirements I
FYI --
Margaret
Date: Wed, 19 Mar 2003 04:01:09 +0100
From: Leif Johansson [EMAIL PROTECTED]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
To: [EMAIL PROTECTED], [EMAIL PROTECTED], Keith Moore [EMAIL PROTECTED],
Margaret
Jim,
Agreed. But how can a node find an address without MUST DNS. The point
is that a requirement to use is based on the situation. My point last
night.
The earlier drafts used different language to try to capture these
conditional requirements. The WG did not like the terms
4.5.1 IP Version 6 Addressing Architecture - RFC2373
The IPv6 Addressing Architecture [RFC-2373] MUST be supported.
Currently, this specification is being updated by [ADDRARCHv3].
This has changed now.
Will update, thanks.
ALso we need to reference Multi6 could affect
this
Jim,
Hosts MAY support mobile node functionality.
This should be SHOULD. The changing specs are not or can be an issue
but this document is riddled with changing specs.
I don't believe that servers, for example, need to implement mobile
node functionality. If a node is fixed and will
Has Multi6 done anything that we we can reference?
Nope. Just heads up. It hopefully will be transparent.
[p.s.] Him majordomo appears to have dropped me from
[EMAIL PROTECTED] could someone at Sun check. I sent mail but it
bounced ? thanks
/jim
John,
Jim,
Hosts MAY support mobile node functionality.
This should be SHOULD. The changing specs are not or can
be an issue
but this document is riddled with changing specs.
I don't believe that servers, for example, need to implement
mobile node functionality. If a
John,
The earlier drafts used different language to try to capture
these conditional requirements. The WG did not like the
terms (Unconditionally Mandatory,
Conditionally Mandatory and Unconditionally Optional), so we
dropped them. There seemed to be comments that we should
stick to
On Wed, 19 Mar 2003, Bound, Jim wrote:
mobile node functionality. If a node is fixed and will not
move, what use is mobile node functionality?
A server in a helicopter or plane is mobile for a few applications. I
understand I am trying to make a point that this exercise needs to be
On Wed, 19 Mar 2003, Bound, Jim wrote:
- Node Reqs 3GPP services
- Node Database Services
- Node Requirements iSCSI/IP
Etc Etc.
The scope is to narrow currently.
One would think that one could exercise own judgment and listen to the
customers (if applicable) when deciding which
Pekka Savola wrote:
unintentionally is exactly what it means, so there is no problem
doing this edit. This is related the API-issue above, as the
interface is required for the applications to be able to specify
which packets belong to which flow. No raw socket is needed for the
fiddling,
On Tue, Mar 18, 2003 at 05:40:02AM +0100, Johan Ihren wrote:
Someone has to implement these things, burn code into proms and ship
products. That process is not simplified by having several alternate
mechanisms available. From an implementation point of view it would be
much preferable to
Hi all,
With all due respect, I think this is short sighted. Today you almost
cannot buy a DSL router for home use that doesn't have an integrated
DHCP server, among all kinds of other strange stuff. To make a future
equivalents of such devices also talk DHCPv6 is clearly possible.
24 matches
Mail list logo
