Thomas,
At 05:57 PM 05/16/2005, Thomas Narten wrote:
Bob,
> This raises the question I have had for a while, is when doing updates to
> existing standard what to put in the IANA section. It seems to me it
> should be what changes should be made to the IANA registries, not a
> complete copy. This
Bob,
> This raises the question I have had for a while, is when doing updates to
> existing standard what to put in the IANA section. It seems to me it
> should be what changes should be made to the IANA registries, not a
> complete copy. This is very different from the technical content of t
Thomas,
Somewhat related, I think it would be helpful to add something like the
following to the IANA considerations for addr arch (which is
effectively empty at the moment w.r.t. to allocation issues):
IANA considerations for the management of global unicast address
space can be found in [
> As I mentioned, Bob will be updating the addressing arch to incorporate
> text to clarify the R & P bits. We will ensure that the language is
> consistent.
Sounds good. I guess the thing to do now is see what the proposed
text says.
Thanks,
Thomas
Hi Thomas,
On May 16, 2005, at 16:02, Thomas Narten wrote:
Hi Brian.
Wouldn't it make sense for this document to at least mention that
there is a synchronization error in terminology used by IANA with
respect to terminology used in this document?
Personally, I don't think so. The addressing archi
> Wouldn't it make sense for this document to at least mention that
> there is a synchronization error in terminology used by IANA with
> respect to terminology used in this document?
I agree that if there is a synchronization issue between IANA and our
docs, and our docs are correct, there is no
Hi Brian.
> > Wouldn't it make sense for this document to at least mention that
> > there is a synchronization error in terminology used by IANA with
> > respect to terminology used in this document?
> Personally, I don't think so. The addressing architecture actually
> points at RFC 2375 which
Fair enough.
--> -Original Message-
--> From: Brian Haberman [mailto:[EMAIL PROTECTED]
--> Sent: Monday, May 16, 2005 3:08 PM
--> To: Gray, Eric
--> Cc: ipv6@ietf.org; Margaret Wasserman; Thomas Narten
--> Subject: Re: last minute review of
--> draft-ietf-ipv
Subject: Re: last minute review of
--> draft-ietf-ipv6-addr-arch-v4-03.txt
-->
--> Hi Thomas,
-->
--> On May 12, 2005, at 12:50, Thomas Narten wrote:
-->
--> > I know this is late, but better late than never...
--> >
--> > Overall, the document is good, but I think
--> -Original Message-
--> From: [EMAIL PROTECTED]
--> [mailto:[EMAIL PROTECTED] Behalf Of
--> Brian Haberman
--> Sent: Monday, May 16, 2005 2:28 PM
--> To: Thomas Narten
--> Cc: Margaret Wasserman; ipv6@ietf.org
--> Subject: Re: last minute review of
--> d
Hi Thomas,
On May 12, 2005, at 12:50, Thomas Narten wrote:
I know this is late, but better late than never...
Overall, the document is good, but I think that the document would
benefit from slight tweaking w.r.t. to multicast. I.e., I assume that
an "addressing architecture" should be complete and
On Thu, 12 May 2005, Thomas Narten wrote:
This section only mentions the T flag, and not the P flag. That doesnt
seem right, since the P flag is clearly in use now and not "0". Was
there a concern about a possible normative reference? I don't think
there needs to be. Suggestion:
Old:
> Or, maybe it's the case that RFC 3307 is (now) the definitive
> document? (IANA doesn't seem to have picked up anything from
> there...).
Update (thank you google!):
http://www.iana.org/assignments/perm-mcast-groupids
Which is findable under "IPv6 Multicast Permanent Group Identifiers"
on the
I know this is late, but better late than never...
Overall, the document is good, but I think that the document would
benefit from slight tweaking w.r.t. to multicast. I.e., I assume that
an "addressing architecture" should be complete and at a minimum offer
pointers to the relevant pieces. I don'
14 matches
Mail list logo
