Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

Julian Reschke wrote: ... In the meantime, draft-iab-streams-headers-boilerplates is in AUTH48, and I have updated my document with the current changes; see , in particular (change

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

Julian, You wrote: > > This problem was reported over three weeks ago. Are we really incapable > to fix something simple like that within three weeks? We are at a point where making trivial changes to headers and boilerplates leads to discussion about more substantive matters and causes eve

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

On 2009-12-22, at 04:57, John C Klensin wrote: > Let me say this a little more strongly. This proposal > effectively modifies RFC 5321 for one particular domain name at > the same time that it effectively (see notes by others) > advocates against coding the relevant domain name into anything > o

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

Hi Olafur, At 21:22 21-12-2009, Olafur Gudmundsson wrote: Correction the message should have been: http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html The changes that Ted Hardie asked for does not address my concern as my comment was about the example in Section 3: "Installing

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

On Mon, 21 Dec 2009, SM wrote: > > If I understood the story, it is to get compliant MTAs not to attempt mail > delivery to domains which do not wish to accept mail. This does not really > solve the implicit MX question but that's another story. The idea of using sink.arpa as an MX target (like t

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

On 2009-12-22, at 11:33, SM wrote: > This draft requires IAB review and approval. You'll note that we asked for it in section 6. > The following paragraph may require some scrutiny: > > "INVALID is poorly characterised from a DNS perspective in > [RFC2606]; that is, the specificatio

Re: Most bogus news story of the week

Given the circumstances, it is probably premature to assume that many ITU people are aware of the proposal at issue here, it indeed it is a formal proposal at all. On Mon, Dec 21, 2009 at 3:45 AM, Florian Weimer wrote: > * Richard L. Barnes: > >> Is this disingenuous or has the ITU really not hea

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

On Mon, Dec 21, 2009 at 11:14 PM, John C Klensin wrote: > > Olafur, > > It seems to me that Ted's message asks for more clarity about > what is being specified, actual review by email-related groups > of email-related records and their implications, and so on. > Certainly I agree with those reques

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

On Mon, 21 Dec 2009, John C Klensin wrote: > > If implicit MXs continue to be permitted, this proposal, as I understand > it, would not work. I believe it will work. RFC 5321 explains it twice: If an empty list of MXs is returned, the address is treated as if it was associated with an impli

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

At 05:50 22-12-2009, Tony Finch wrote: What issue? As far as I can tell there's no conflict between Joe's draft and RFC 5321, except that the choice of words in the example needs improvement. The wording in the draft is at odds with what is in RFC 5321. This can be discussed in the relevant w

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

On Tue, 22 Dec 2009, SM wrote: > At 05:50 22-12-2009, Tony Finch wrote: > > > > What issue? As far as I can tell there's no conflict between Joe's draft > > and RFC 5321, except that the choice of words in the example needs > > improvement. > > The wording in the draft is at odds with what is in RF

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

On 2009-12-22, at 18:32, SM wrote: > At 06:23 22-12-2009, Joe Abley wrote: > >> On 2009-12-22, at 11:33, SM wrote: >> >> The goal was to provide a set of additional requirements that the IAB would >> take into consideration when carrying out the duties as described in 3172. >> For example, so

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

> FWIW, the document allows the RFC editor some headway in maintaining the > language in the style guide. Maybe we^H^Hthe IAB should have aimed at full delegation of the boilerplate, exactly as for the Trust-maintained boilerplate. For now, there are indeed weasel words such as: "However, thi

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

Dave: I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. Russ At 02:39 PM 12/22/2009, Dave CROCKER wrote: Brian, This seems worth being a bit pedantic about, to make sure we all share the same understanding: I take your int

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

On Dec 22, 2009, at 12:08 PM, Russ Housley wrote: > Dave: > > I agree with Birain's assessment. The RFC Editor can handle this issue > without delaying publication of the document. +1 Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/ma

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

At 11:05 22-12-2009, Joe Abley wrote: Why? Some future IAB would have a list of names and the appropriate reference. The purposes of the document under review is described fairly succinctly in section 1: 1. to create a new IANA registry called "ARPA Reserved Names" (see Section 4

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

All, I agree with Birain's assessment. The RFC Editor can handle this issue without delaying publication of the document. +1 Me too. Publish the RFC. Please. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/

Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

--On Tuesday, December 22, 2009 08:55 -0800 Ted Hardie wrote: >... > Hi John, > > My take on this is that this idea is worth exploring, and this > document can take us down the right road for that by adding > the caching clarification and removing the examples. Removing > the apparent force o