dor or by the vendor providing the material for documenting their
usage to Bernie Volz (mailto:[EMAIL PROTECTED]) for inclusion in a general
draft documenting several options.
Once the Internet Draft has been published, it will be, at the vendor's
discretion, published as an Informational RFC or ent
Internet (ISPs network) any packet that
does not have a source address that is valid from that site.
I would hope that lots of ISPs already do this. But, perhaps not.
- Bernie Volz
Process Software
not in the computer
field and so it is not an issue.
- Bernie Volz
-Original Message-
From: John Stracke [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 06, 2000 4:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Bake-off as trademark
"Henning G. Schulzrinne" wrote:
> I've been
d advance that draft to an RFC. The
Internet Draft can either be written by the vendor or by the
vendor providing the material for documenting their usage to
Bernie Volz (mailto:[EMAIL PROTECTED]) for inclusion in a
general draft documenting several options.
Once the Internet Draft has been p
Hi:
I'm now pulling together the final list of DHCPv4 options between 128 to
223 (inclusive) that are currently in use as per RFC 3942
(http://www.ietf.org/rfc/rfc3942.txt): "Reclassifying DHCPv4 Options".
The 6-month notification period has expired.
- Bernie Volz
> ---
This would, as Ted indicates, greatly complicate the entire update
sequence. The current update sequence (see
draft-ietf-dhc-ddns-resolution-10.txt), never does a query of the RRs in
the server. Therefore, either we'd have to do a query first to obtain
the DHCID RR and extract the algorithm so we c
Pekka:
Regarding your one major issue, the updater is NOT the entity that gets
to decide whether to allow any DNS update to occur or not. It is the DNS
server that restricts who can do updates and what they can update.
We're assuming that the most likely entity to be given fairly open
access to a
is more
likley to do adds/removes of individual RRs.
Do we really need to get into this level of specificity around this?
- Bernie
> -Original Message-
> From: Pekka Savola [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 2005 3:37 AM
> To: Bernie Volz (volz)
> Cc: iesg@ie
> I confess that I don't see the problem. The updater would do a DNS
> query for DHCID RRs; it would be given all of the stored
> records.
That's not how the current update algorithm works. Sure, we could do
almost anything but we'll be debating this for the next 100 years. It
has already gone
BTW, whatever algorithm you use (SHA-256 or even something much more
complex) is not going to help -- it may make the work someone has to do
a bit more involved, but it really doesn't make it impossible.
1. You always have a brute force attack. As you indicate, calculating
the hash based on the ma
]
> Sent: Monday, November 28, 2005 5:14 PM
> To: Bernie Volz (volz); Steven M. Bellovin; Ted Lemon
> Cc: dhcwg@ietf.org; Pekka Savola; ietf@ietf.org;
> namedroppers@ops.ietf.org
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
> Call: 'Resolution ofFQDN Conflic
BTW: Just to be clear, the MD5 hash is calculated using both the client
identifier AND the domain name. But the domain name is known (it is the
entry under which the DHCID RR lives).
However, this means that the DHCID data for a client changes with its
name.
The RDATA for all type codes other
> >> Through the use of the client
> >>FQDN option, DHCP clients and servers can negotiate the
> client's FQDN
> >>and the allocation of responsibility for updating the
> DHCP client's A
> >>and/or RRs.
> >>
> >> ==> also PTR records, not just A/..
> >
> > No. Only A/AAA
How about we address issue 1 by expanding the DHCID RR type code. We
have 16-bits and we're just using 4 values presently. There's plenty of
room for future expansion *SHOULD* someone come along and demand a new
algorithm in the future. I can't see why this would EVER occur since
this really isn't
er 04, 2005 11:43 PM
> To: Bernie Volz (volz); Sam Hartman; Mark Stapp (mjs)
> Cc: namedroppers@ops.ietf.org; ietf@ietf.org; Pekka Savola;
> Ted Lemon; iesg@ietf.org; dhcwg@ietf.org; Steven M. Bellovin;
> Jeffrey Hutzelman
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Las
Robert:
The reason to allow this is that otherwise client A will be unnecessarily
reconfigured many times. (It is also possible that a client might Renew on its
own just as this is happening and thus it can also be removed from the
Reconfigure.)
I think the text should be cleaned up to indicat
ally broken.
But I don't really see this as a big issue and the "must" is the lower-case
variant anyway.
- Bernie
-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]
Sent: Monday, April 29, 2013 9:45 AM
To: mohamed.boucad...@orange.com
Cc: Bernie Volz (volz
While this is certainly an interesting point, I don't really see that it
is specific to the container option or that the container option adds
any new or different issues?
I don't see why this would hold up this draft (perhaps it is not holding
it up)? Perhaps at most some statement(s) about the i
Son [mailto:g...@rim.com]
Sent: Wednesday, April 15, 2009 9:53 AM
To: Ted Lemon; Ralph Droms (rdroms)
Cc: mif; ietf@ietf.org; black_da...@emc.com; dhc WG; gen-...@ietf.org;
Bernie Volz (volz)
Subject: RE: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
I think Ted pointed out ver
-Original Message-
From: Scott Brim [mailto:s...@employees.org]
Sent: Wednesday, April 15, 2009 4:52 PM
To: Ted Lemon
Cc: Ralph Droms (rdroms); Bernie Volz (volz); dhc WG; gen-...@ietf.org;
black_da...@emc.com; ietf@ietf.org; mif
Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
20 matches
Mail list logo
