Title: Comments for rc2461bis
Thanks
for your comments. I'll prepare new issues/responses
as
needed and get back to each one separately.
Hesham
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Elwyn DaviesSent:
Wednesday, August 04, 2004 12:10
Title: Samsung Enterprise Portal mySingle
Greg, thanks your comments and see my comments (inline)
>I was concerned that M|O could be used to
>invoke DHCP information-requests
>(rather than just O).
rather than just O ?
This draft wrote as below;
[RFC3736] is just a subset of full DHCPv6.
Alex,
Thanks.. I will update the text in the next rev.
Regards
Mukesh
> -Original Message-
> From: ext Alex Conta [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 05, 2004 8:55 PM
> To: Gupta Mukesh (Nokia-NET/MtView)
> Cc: [EMAIL PROTECTED]
> Subject: Re: Section 2.4, item (f) of draf
Mukesh,
A first sentence like:
"The rate-limiting parameters SHOULD be configurable per node,
if the node has similar speed/bandwidth interfaces, and/or per
interface, if the node has disimilar speed/bandwidth interfaces".
or
"The rate-limiting parameters SHOULD be configurable per node,
if the n
As for the issue #2,
our main goal is to *generate* unique multicast addresses - /96
automatically (like RFC 3306) without any fear of conflicts.
"Any fear" is subjective. It is completely possible that a node
might start to send an SSM stream to that particular multicast
address.
And remember
Bob,
> 3. Requests for new type value assignments from outside of the
>IETF should be sent to the IETF for review at <[EMAIL PROTECTED]>.
>The general guideline for this review is that the assignment for
>a single type value should be made if there is public and open
>
Alex,
Thanks for pointing this out. What do you think about the following
as the replacement text?
=
The rate-limiting parameters SHOULD be configurable. In the
case of a token-bucket implementation, the best defaults depend
on the computational power of the
All,
I have put the slides from the meeting up on
the web. Comments/questions welcome.
http://www.innovationslab.net/~brian/IETF60/IPv6/
Regards,
Brian
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Re
Pakka,
One could ask them to be Cc'ed to [EMAIL PROTECTED] Their
business is ticketing the messages and making sure things don't fall
under the cracks?
I agree. I send comments on this topic to the authors of RFC2434
"Guidelines for writing an iana considerations" suggesting something
similar.
At 11:20 AM 08/05/2004, Brian E Carpenter wrote:
Sure, if the IESG agrees, this is fine.
Thanks,
Bob
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
On Thu, 5 Aug 2004, Bob Hinden wrote:
> I agree that saying "sending to the IETF" is not workable and the
> instructions need to be more explicit. Since this topic since this comes
> up in many drafts, I wonder if the IETF should set up a specific alias that
> these requests can be sent to so t
Sure, if the IESG agrees, this is fine.
Brian
Bob Hinden wrote:
Brian,
At 04:06 PM 08/04/2004, Brian E Carpenter wrote:
I've read this since I left the microphone. I stick to my guns -
the statement "Requests for type value assignments from outside of the
IETF should be sent to the IETF for revi
The last paragraph of Section 2.4, item (f) of
draft-ietf-ipngwg-icmp-v3-04.txt is pointing to ICMP rate limiting
configurability on a per node basis.
ICMP Rate-limiting configurability makes sense also on a per interface
basis.
In a case of a router having different speed/bandwidth interfaces
Brian,
At 04:06 PM 08/04/2004, Brian E Carpenter wrote:
I've read this since I left the microphone. I stick to my guns -
the statement "Requests for type value assignments from outside of the
IETF should be sent to the IETF for review." is too vague and needs to
be more specific, as in
"should be a
Mohacsi Janos wrote:
On Thu, 5 Aug 2004, Kurt Erik Lindqvist wrote:
On 2004-08-05, at 02.06, Tony Hain wrote:
The IETF will never resolve the tension between the network
administrator
and the system administrator. That is a local CIO function in each
organization. It is reasonable for the security
Hi Jinmei,
Sorry about the confusion.
- Original Message -
From: JINMEI Tatuya / <[EMAIL PROTECTED]>
Date: Thursday, August 5, 2004 7:31 am
Subject: regarding some comments on the M&O draft
> Hello,
>
> I'm not sure if I understand your comments on
> draft-daniel-ipv6-ra-mo-flags-
Hello,
I'm not sure if I understand your comments on
draft-daniel-ipv6-ra-mo-flags-00.txt in the wg meeting. (I've checked
the jabber log to be sure, but I'm still not 100% sure). Would you
mind to repeat those?
To provide some answers at the moment:
As for the comment on policy 1 (always try
On Thu, 5 Aug 2004, Kurt Erik Lindqvist wrote:
On 2004-08-05, at 02.06, Tony Hain wrote:
The IETF will never resolve the tension between the network
administrator
and the system administrator. That is a local CIO function in each
organization. It is reasonable for the security considerations sectio
18 matches
Mail list logo
