RE: draft-ietf-ipv6-node-requirements-11.txt

2006-01-06 Thread john . loughney
I'll take a look at all of this on Monday and work text up. I'll send the text to the WG, and if there is agreement, I can make the updates during AUTH48. John >-Original Message- >From: ext Dave Thaler [mailto:[EMAIL PROTECTED] >Sent: 06 January, 2006 23:31 >To: Loughney John (Nokia-

RE: draft-ietf-ipv6-node-requirements-11.txt

2006-01-06 Thread Dave Thaler
Here's another one: RFC2893 is now obsoleted by RFC4213 Section 6.l.1 says: "RFC 2893 is currently being updated." > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Dave Thaler > Sent: Thursday, January 05, 2006 3:05 PM > To: [EMAIL PROTECTED] > Cc: i

Re: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt

2006-01-06 Thread JORDI PALET MARTINEZ
Title: Re: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt I think there has not been any agreement to proceed with that in any RIR at the time being, but I’m not 100% sure. My personal opinion is also that we should not do that change. I think is more possible to agree on the HD

Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt

2006-01-06 Thread Dwight Jamieson
Title: Question regarding draft-narten-ipv6-3177bis-48boundary-00.txt There was some discussion at the Paris IPv6 WG meeting about allocating /56 to small end sites. There was a suggestion that the IAB comment regarding this policy. I am a member of the ATIS IPv6 task force http://www.atis

Sending ICMP error upon receiving an NA without SLLAO in 2461bis

2006-01-06 Thread Soliman, Hesham
Hi all, This is a mini concensus call on the discussion I had with Jinmei below. The basic issue left is whether we should allow a node to send an ICMP error due to the reception of an NA without the SLLAO. The reason for sending the ICMP error is to inform upper layers that the communication

Re: draft-ietf-ipv6-node-requirements-11.txt

2006-01-06 Thread Brian E Carpenter
IMHO, the reference updates should be done during AUTH48 without further discussion, but making AH optional seems like a substantive change. Personally, I would support that change, i.e. s/MUST/MAY/. Brian (speaking only for myself) Jari Arkko wrote: They should be updated. By the way I no

FW: IPv6 WG Last Call:

2006-01-06 Thread Pashby, Ronald W CTR NSWCDD-B35
I was confused when I read the draft about the change to the multicast address. I reread the draft and realized where the confusion arrises in the second paragraph of section 5 it states: "Append the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2:FF::/104." Should this

Re: draft-ietf-ipv6-node-requirements-11.txt

2006-01-06 Thread Pekka Savola
On Fri, 6 Jan 2006, Jari Arkko wrote: By the way, there are also substantive changes in the new IPsec documents. For instance, AH support is no longer a MUST. I think this should be reflected in the node requirements document too, as that currently says "AH [RFC-2402] MUST be supported.". There'

Re: draft-ietf-ipv6-node-requirements-11.txt

2006-01-06 Thread Jari Arkko
They should be updated. By the way I noticed recently that the RFC Editor does not necessarily do "obsoleted by" updates to references automatically. This stuff needs to be done by the authors in AUTH48. And in this particular case we have even text changes, as you point out. By the way, there ar