Dear str4d,
I've updated the drafts in Git as suggested. Thanks for the careful review.
Christian
On 10/02/2015 07:33 AM, str4d wrote:
> Christian Grothoff wrote:
>> Dear DNSOP / chairs,
>
>> The same applies to the various P2P drafts:
>
>> https://datatracker.ietf.org/doc/draft-grothoff-iesg-
Hi David,
On 4 Oct 2015, at 14:00, David Conrad wrote:
> On Oct 2, 2015, at 9:10 AM, Suzanne Woolf wrote:
> Preempting a WGLC, I support the document. It states its aim of
> documenting existing practices, and it does so clearly.
I agree completely. I am actually confused as t
> Your co-chair is a little confused.
Sorry about that.
On Oct 4, 2015, at 2:00 PM, David Conrad wrote:
>> I've since been told that the draft doesn't actually document current
>> practice (don't know the details), so this probably needs to be fixed.
>
> What "needs to be fixed"? That the draf
All,
Your co-chair is a little confused.
On Oct 4, 2015, at 2:00 PM, David Conrad wrote:
> I've since been told that the draft doesn't actually document current
> practice (don't know the details), so this probably needs to be fixed.
What "needs to be fixed"? That the draft doesn't document c
Hi,
On Oct 2, 2015, at 9:10 AM, Suzanne Woolf wrote:
Preempting a WGLC, I support the document. It states its aim of
documenting existing practices, and it does so clearly.
>>>
>>> I agree completely. I am actually confused as to why it is not already
>>> an RFC.
>>
>> +1
I've since
Admin note: the WGLC has concluded. Thanks everyone for your comments, and the
authors for addressing them. We'll be reviewing all of the correspondence with
the authors and have an official followup soon on moving this draft forward.
Suzanne & Tim
___
On Sun, Oct 4, 2015 at 7:32 AM, Dave Lawrence wrote:
> A couple of quick observations:
>
> * The draft says that the answer in a signed zone MAY be unsigned.
> Since this will ultimately cause a SERVFAIL for validating
> resolvers, it is not really acceptable.
>
You and Evan,
are right we w
Thank you, Jinmei, for your thoughtful feedback.
Jinmei writes:
> It would be nicer if it can be clarified before advancing
> it: are we expecting newer implementations are developed based on this
> specification, or is this document literally for describing the
> current practice for the record (
A couple of quick observations:
* The draft says that the answer in a signed zone MAY be unsigned.
Since this will ultimately cause a SERVFAIL for validating
resolvers, it is not really acceptable.
* The draft does not describe at all what the proper behaviour is for
an owner name that has
