At Mon, 18 Jan 2016 17:56:24 +0200,
Andreas Gustafsson wrote:
> > Can you point to specific wording that needs changing?
>
> Mainly, the "Updates: 2136", and each instance of "UPDATE client".
> For example, in the Introduction, you could change
>
>While these methods interoperate well with DN
Tony Finch wrote:
> I meant precedents specific to DNS UPDATE.
RFC 4703 specifies DNS UPDATE behavior for one class of clients
without updating RFC 2136, and without framing it as a "requirement
on UPDATE clients".
> Can you point to specific wording that needs changing?
Mainly, the "Updates: 21
Andreas Gustafsson wrote:
> Tony Finch wrote:
> > Hmm, I am reluctant to introduce new layering. Is there a precedent for
> > the distinction you are making?
>
> Any web standard could be said to specify "requirements on HTTP clients",
> yet most of them don't use that term or update the HTTP spec
Tony Finch wrote:
> Hmm, I am reluctant to introduce new layering. Is there a precedent for
> the distinction you are making?
Any web standard could be said to specify "requirements on HTTP clients",
yet most of them don't use that term or update the HTTP specification.
Any mail standard could be
Andreas Gustafsson wrote:
>
> Here's my opinion:
Thanks :-)
> Section 9 of the draft should not refer to the requirements as
> "requirements for UPDATE clients", but something like "requirements for
> entities that update endpoint records in the reverse tree". I would
> consider these entities
Tony Finch wrote:
> 神明達哉 wrote:
>
> > - Does rfc2317bis really "update" RFC2136 in the first place? It
> > certainly provides some additional client behavior that uses
> > RFC2136, but it doesn't seem to require any change to RFC2136 itself
> > (am I overlooking something?).
>
> The purpo
神明達哉 wrote:
> - Does rfc2317bis really "update" RFC2136 in the first place? It
> certainly provides some additional client behavior that uses
> RFC2136, but it doesn't seem to require any change to RFC2136 itself
> (am I overlooking something?).
The purpose of that part of the RFC is to i
On 1/13/16 12:23 PM, 神明達哉 wrote:
With this understanding I have two followup questions:
- If a document is marked as "Updates ", does it
automatically mean its status should be Standards Track, too?
It would go in as "Proposed Standard"
tim
__
At Wed, 13 Jan 2016 10:13:42 +,
Tony Finch wrote:
> > - I wonder why its intended status is standards track. It generally
> > just talks about operational techniques rather than describe some
> > new protocol, so a BCP seems to be more appropriate (in fact RFC2317
> > is a BCP). Perha
神明達哉 wrote:
>
> - I wonder why its intended status is standards track. It generally
> just talks about operational techniques rather than describe some
> new protocol, so a BCP seems to be more appropriate (in fact RFC2317
> is a BCP). Perhaps it's because this document will "update" RFC21
At Sun, 13 Dec 2015 22:08:13 -0500,
Tim Wicinski wrote:
> This starts a Call for Adoption for draft-fanf-dnsop-rfc2317bis
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-fanf-dnsop-rfc2317bis/
>
> Please review this draft to see if you think it is suitable for adoption
>
On Sun, Dec 13, 2015 at 10:08 PM, Tim Wicinski wrote:
> Working Group,
>
> There has been a bit of discussion on this update, and it's time to do a
> Call for Adoption.
>
> This starts a Call for Adoption for draft-fanf-dnsop-rfc2317bis
>
> The draft is available here:
> https://datatracker.ietf.
12 matches
Mail list logo
