Robert:IANA follows the rules to make these assignments.See https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml162OPTION_V4_DNRNEncrypted DNS Server[RFC-ietf-add-dnr-13]And https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml144OPTION_V6_DNRYesNo
Section 9 of https://datatracker.ietf.org/doc/draft-ietf-add-dnr/13/ does
indeed request those assignments. And given that RFC-editor is working on
converting this into an RFC, IANA must make the assignments for the RFC to be
published.
- Bernie (from iPad)
> On Feb 21, 2023, at 10:54 AM, moha
Thanks for the review and we’ll look to address your nits in a future revision
(after IETF last-call ends).
- Bernie
> On Dec 26, 2024, at 11:45 AM, Dale Worley via Datatracker
> wrote:
>
> Reviewer: Dale Worley
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for thi
t; From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 2005 10:02 AM
> To: gen-art@ietf.org
> Cc: [EMAIL PROTECTED]; Mark Stapp (mjs);
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; Bernie Volz (volz);
> Ralph Droms (rdroms); [EMAIL PROTECTED]; Sam Hartman
&
We are in the process of re-chartering. (Whether this document is included in
that new charter will depend on timing as it would be unnecessary to include it
if it is already 'done'.)
The draft proposed rechartering (which has some minor updates since then), is
at http://datatracker.ietf.org/d
Perhaps we should get away from whether something is easy or difficult to
implement or whether the algorithm may be more (or less) efficient.
I think the point of this material is to ENCOURAGE random assignment rather
than sequential to improve privacy- so keep it at that. Let implementers worry
, February 16, 2016 4:39 AM
To: Bernie Volz (volz) ; Robert Sparks ;
Tomek Mrugalski ; General Area Review Team
; i...@ietf.org; dh...@ietf.org;
draft-ietf-dhc-dhcpv6-privacy@ietf.org
Subject: Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
Bernie,
On 02/15/2016 06:37 PM, B
Elwyn:
On behalf of the authors of draft-ietf-dhc-rfc3315bis, thanks much for the very
thorough review (most of your comments look appropriate to apply).
- Bernie
-Original Message-
From: Elwyn Davies [mailto:elw...@dial.pipex.com]
Sent: Thursday, January 18, 2018 1:00 PM
To: gen-art@i
I’ll update and put out a -13 over the weekend.
s20.3, para 2:
> This method MUST be supported by all protocols.
This seems to be rather presumptious!
I’ll fix this as it is supposed to ne all Authentication option protocols.
- Bernie (from iPad)
On Apr 6, 2018, at 7:29 PM, Elwyn Davies
mailt
e name of the option “IA Prefix”.
The -13 has been published.
Thanks Elwyn for the re-review and comments!
* Bernie
From: Bernie Volz
Date: Friday, April 6, 2018 at 7:52 PM
To: Elwyn Davies
Cc: Suresh Krishnan , General Team ,
"draft-ietf-dhc-rfc3315bis@ietf.org"
Subjec
Hi.
One comment (as DHC WG co-chair and shepherd). See inline below (BV>).
Other comments/responses seem OK.
- Bernie
-Original Message-
From: ianfar...@gmx.com
Sent: Tuesday, September 11, 2018 7:42 AM
To: Elwyn Davies
Cc: gen-art@ietf.org; draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.
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; i...@ietf.org; black_da...@emc.com; dhc WG; gen-art@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-art@ietf.org;
black_da...@emc.com; i...@ietf.org; mif
Subject: Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00
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
Hi Roni:
Sorry for the late response to this review. Thanks for doing it!
>1. In the terminology section I was wondering why the client is a device while
>the server is a software. Any reason for this distinction.
I can easily replace both with "node" as that matches RFC8415:
So:
client
Interesting that the datatracker says the document is "Proposed Standard", but
the document has "Intend status: Informational". The two should be made to
agree.
- Bernie
> On Sep 9, 2020, at 8:45 PM, Fernando Gont wrote:
>
> Hello, Pete,
>
> Thanks a lot for your feedback! In-line
>
>
18 matches
Mail list logo
