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

2009-12-22 Thread Julian Reschke

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 
http://tools.ietf.org/html/draft-reschke-hab-01, in particular 
http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change 
list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt 
(diffs).

...


I just heard that the RFC 5741-to-be is not going to be fixed with 
respect to the stutter in the boilerplate, such as in:


-- snip --
3.1.6.2. Text of 'Status Of This Memo'


   This document is not an Internet Standards Track specification; it is
   published for the historical record.

   This document defines a Historic Document for the Internet community.
   This document is a product of the Internet Engineering Task Force
   (IETF).  It has been approved for publication by the Internet
   Engineering Steering Group (IESG).  Not all documents approved by the
   IESG are candidate for any level of Internet Standards; see Section 2
   of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc.
-- snip --

(see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2).

This problem was reported over three weeks ago. Are we really incapable 
to fix something simple like that within three weeks?



Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Olaf Kolkman


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 even more delay, 
folk wanted it done. It is unfortunate that the stutter (I agree its there and 
that its ugly) remains in the document. 

Headers and boilerplates lives on this tangent between community wishes, RFC 
oversight, and RFC Editor series continuity and style. Having learned from 
getting HB done, I believe that in the future such efforts should be pulled by 
the RSE, with IAB oversight and not by the IAB with RFC-Editor input.


FWIW, the document allows the RFC editor  some headway in maintaining the 
language in the style guide.

--Olaf

[top-post, full context below.]





On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote:

 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 
 http://tools.ietf.org/html/draft-reschke-hab-01, in particular 
 http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change 
 list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt 
 (diffs).
 ...
 
 I just heard that the RFC 5741-to-be is not going to be fixed with 
 respect to the stutter in the boilerplate, such as in:
 
 -- snip --
 3.1.6.2. Text of 'Status Of This Memo'
 
 
This document is not an Internet Standards Track specification; it is
published for the historical record.
 
This document defines a Historic Document for the Internet community.
This document is a product of the Internet Engineering Task Force
(IETF).  It has been approved for publication by the Internet
Engineering Steering Group (IESG).  Not all documents approved by the
IESG are candidate for any level of Internet Standards; see Section 2
of RFC 5741.
 
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc.
 -- snip --
 
 (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2).
 
 This problem was reported over three weeks ago. Are we really incapable 
 to fix something simple like that within three weeks?
 
 
 Best regards, Julian
 ___
 rfc-interest mailing list
 rfc-inter...@rfc-editor.org
 http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

 

Olaf M. KolkmanNLnet Labs
   Science Park 140, 
http://www.nlnetlabs.nl/   1098 XG Amsterdam

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Joe Abley

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
 or treating it in a special way.  That combination doesn't seem
 to me to work.

If that's the consensus of SMTP experts, then I would be more than happy to rip 
that example out (or the whole section, to be honest). I was quite enthusiastic 
about the previous revision's conscious decision not to include examples at all.

Incidentally, the other stories remark in the subject line was a reference to 
the fact that the document instantiates a registry which can be used by others 
to document particular characteristics of records in the ARPA zone. It wasn't 
intended to refer to the examples section (which, as I mentioned, was added 
only recently).


Joe

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread SM

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 an MX record whose RDATA includes SINK.ARPA in the
   EXCHANGE field ([RFC1034]) should cause compliant MTAs to make
   no connection: SINK.ARPA does not exist, and A and  records
   should not be used when an MX record is present.

I am aware of the operational angle and that the above has been on 
the SMTP shopping list for some time.  I am not sure whether it 
solves the problem instead of the symptom.  I won't suggest an 
informative reference to RFC 1882. :-)


If SMTP is to be the topical example, you may wish to get the draft 
reviewed by a mail-related working group.  The shortest path would be 
to drop the first example.


This draft requires IAB review and approval.  The following paragraph 
may require some scrutiny:


 INVALID is poorly characterised from a DNS perspective in
  [RFC2606]; that is, the specification that INVALID does not exist
  as a Top Level Domain (TLD) is imprecise given the various uses of
  the term TLD in policy forums;

Section 5.1 is quite a change compared to what is in Section 2.1 of 
RFC 3172.  The existing text says:


  'The arpa sub-domains are used for those protocol object sets
   defined as part of the Internet Standards Process [4], and are
   recommended to be managed as infrastructure protocol objects.'

This proposal turns it into a registry of ARPA Reserved Names where 
the registration procedure is IETF Standards Action and IAB 
approval.  Unless I missed something, there is a lack of clarity 
about what arpa sub-domains will be used for in future.


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Tony Finch
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 the null MX proposal) is
to define a conventional form of MX record that indicates a domain is not
a valid mail domain. It solves the implicit MX problem for sites that use
it, but obviously not for sites that don't. It's much cheaper to deploy
than RFC 1864 (which specifies the SMTP 521 initial greeting).

 Here's some text from Section 5.1 of RFC 5321: [snip]

 As the intended status of this draft is BCP, it may have to take into
 consideration the above text from RFC 5321 and see how to resolve the issue.

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.

In particular, this sentence:
  Installing an MX
   record whose RDATA includes SINK.ARPA in the EXCHANGE field
   ([RFC1034]) should cause compliant MTAs to make no connection:
   SINK.ARPA does not exist, and A and  records should not be
   used when an MX record is present.

ought to be written:
  Installing an MX
   record whose RDATA includes SINK.ARPA in the EXCHANGE field
   ([RFC1035]) shall cause compliant MTAs to make no connection:
   SINK.ARPA does not exist, and A and  records shall not be
   used when an MX record is present.

so that it agrees with the strength of the RFC 2119 mustard in RFC 5321.
Also the reference to RFC 1034 should be a reference to RFC 1035 since
that is where the EXCHANGE field is specified.

Note that any MX target domain name with no A or  RRs will do the same
job as sink.arpa or . (the dns root as proposed in the null MX draft); the
advantage of a conventional name is that MTAs can skip the target address
lookups since they already know the MX is unusable..

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Joe Abley

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 specification that INVALID does not exist
  as a Top Level Domain (TLD) is imprecise given the various uses of
  the term TLD in policy forums;
 
 Section 5.1 is quite a change compared to what is in Section 2.1 of RFC 3172. 
  The existing text says:
 
  'The arpa sub-domains are used for those protocol object sets
   defined as part of the Internet Standards Process [4], and are
   recommended to be managed as infrastructure protocol objects.'
 
 This proposal turns it into a registry of ARPA Reserved Names where the 
 registration procedure is IETF Standards Action and IAB approval.  Unless I 
 missed something, there is a lack of clarity about what arpa sub-domains 
 will be used for in future.

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, some far future IAB might overlook that one obscure document amongst 
the 50,000 that exist specifies that SINK.ARPA should not exist, if that was 
the only place it was documented.

The proposed IANA registry would be useful for such a future IAB in that it 
would list all the names that required special attention, together with a 
reference in each case to the document that described it.

My reading of the text is consistent with the goal as described above. I would 
not object to further clarifying the goal by spelling out that the special 
criteria found via the new proposed registry do not trump the opinion of the 
IAB (i.e. the IAB can still say no, even if the criteria are all met).


Joe
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Most bogus news story of the week

2009-12-22 Thread Phillip Hallam-Baker
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 fwei...@bfk.de wrote:
 * Richard L. Barnes:

 Is this disingenuous or has the ITU really not heard of netflow?

 I can understand if people are not too happy with best-effort
 accounting and billing.

 --
 Florian Weimer                fwei...@bfk.de
 BFK edv-consulting GmbH       http://www.bfk.de/
 Kriegsstraße 100              tel: +49-721-96201-1
 D-76133 Karlsruhe             fax: +49-721-96201-99
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf




-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Ted Hardie
On Mon, Dec 21, 2009 at 11:14 PM, John C Klensin john-i...@jck.com 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 requests and concerns.  Your
 response is fine, except I have no idea what is actually going
 to get done, and what those reviews will produce, until I see
 the results.  And those issues are sweeping enough that I really
 wish the Last Call would be terminated and restarted only when
 those reviews, and a document that reflects them, is in place.

 From that point of view, I'm objecting less to the content of
 this proposal (as far as it goes), but to the fact that the
 ducks don't seem to be lined up prior to its going out to IETF
 Last Call.  The comments below are more substantive.


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 of the examples by
clarifying that they indicate potential future lines of exploration rather than
worked updates to the relevant standards also works for me.  If we
want to explore
the idea in a .bogus.arpa subdomain rather than using sink.arpa, I
don't think that's
a big deal one way or the other.

The real question for me is how do we get off the chicken-and-egg problem?
If we have no document specifying the behavior of a guaranteed non-existent
name, it is hard to get much actual deployment and experience, and I think
that's what is required here.  We may well find that this works in some contexts
and fails utterly in others, based on the silly domain name tricks pulled on
a per-application basis.  But we can't find that out easily without an agreed
upon way of trying this.

Maybe that makes this an experiment; maybe it makes it a likely-to-be-ephemeral
best current practice.  But it does get the egg hatched, and that seems to be
useful to me.

regards,

Ted Hardie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Tony Finch
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 implicit MX RR, with a preference of 0, pointing
   to that host. If MX records are present, but none of them are usable,
   or the implicit MX is unusable, this situation MUST be reported as an
   error.

   If one or more MX RRs are found for a given name, SMTP systems MUST
   NOT utilize any address RRs associated with that name unless they are
   located using the MX RRs; the implicit MX rule above applies only
   if there are no MX records present.  If MX records are present, but
   none of them are usable, this situation MUST be reported as an error.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread SM

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 working group.


At 06:23 22-12-2009, Joe Abley wrote:


On 2009-12-22, at 11:33, SM wrote:
You'll note that we asked for it in section 6.


Yes.

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, some far future IAB might overlook 
that one obscure document amongst the 50,000 that exist specifies 
that SINK.ARPA should not exist, if that was the only place it was documented.


The proposed IANA registry would be useful for such a future IAB in 
that it would list all the names that required special attention, 
together with a reference in each case to the document that described it.


If that is the goal, the draft would have to register all the arpa 
sub-domains.


My reading of the text is consistent with the goal as described 
above. I would not object to further clarifying the goal by spelling 
out that the special criteria found via the new proposed registry do 
not trump the opinion of the IAB (i.e. the IAB can still say no, 
even if the criteria are all met).


The procedures for registration are documented in Section 2.1 and 
Section 3.0 of RFC 3172.  You could reference those sections instead 
of having Section 5.0 and Section 5.1.


The main parts of this draft are about the eternal non-existence of 
sink.arpa.  If the examples are removed, there isn't any text that 
explains the operational utility.  I am not arguing for keeping the 
examples.  The operational utility could be addressed by a project 
similar to AS112.


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Tony Finch
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 RFC 5321.  This can be
 discussed in the relevant working group.

Which wording? Which working group?

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Joe Abley

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, some far future IAB might overlook that one obscure document 
 amongst the 50,000 that exist specifies that SINK.ARPA should not exist, if 
 that was the only place it was documented.
 
 The proposed IANA registry would be useful for such a future IAB in that it 
 would list all the names that required special attention, together with a 
 reference in each case to the document that described it.
 
 If that is the goal, the draft would have to register all the arpa 
 sub-domains.

Why?

 My reading of the text is consistent with the goal as described above. I 
 would not object to further clarifying the goal by spelling out that the 
 special criteria found via the new proposed registry do not trump the 
 opinion of the IAB (i.e. the IAB can still say no, even if the criteria are 
 all met).
 
 The procedures for registration are documented in Section 2.1 and Section 3.0 
 of RFC 3172.

Section 2.1 and 3.0 deal with delegations.

 You could reference those sections instead of having Section 5.0 and Section 
 5.1.

Not really, since the goal is to provide a framework for inserting other 
records into the ARPA zone apart from those associated with delegations.

 The main parts of this draft are about the eternal non-existence of 
 sink.arpa.  If the examples are removed, there isn't any text that explains 
 the operational utility.  I am not arguing for keeping the examples.  The 
 operational utility could be addressed by a project similar to AS112.

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);

   2.  to define the special considerations of a single name SINK.ARPA,
   a name which is defined never to exist (see Section 2);

   3.  to allow the procedures by which the ARPA zone is maintained, as
   documented in [RFC3172], to be modified for names present in the
   ARPA Reserved Names registry according to the special
   characteristics of those names (see Section 5).

Which of those three purposes are you suggesting the AS112 project could help 
with?


Joe
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Brian E Carpenter
 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, this is not
   intended to specify a single, static format.  Details of formatting
   are decided by the RFC Editor.

  These paragraphs will need to be
   defined and maintained as part of RFC stream definitions.  Initial
   text, for current streams, is provided below.

I think this gives the RSE, in conjunction with the tools maintainers,
reasonable flexibility.

I also note:

  The changes introduced by this memo should be implemented as soon as
   practically possible after the document has been approved for
   publication.

which is presumably intended to allow the tools some time to catch up,
again requiring RSE/tools coordination.

Regards
   Brian Carpenter


On 2009-12-22 23:50, Olaf Kolkman wrote:
 
 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 even more 
 delay, folk wanted it done. It is unfortunate that the stutter (I agree its 
 there and that its ugly) remains in the document. 
 
 Headers and boilerplates lives on this tangent between community wishes, RFC 
 oversight, and RFC Editor series continuity and style. Having learned from 
 getting HB done, I believe that in the future such efforts should be pulled 
 by the RSE, with IAB oversight and not by the IAB with RFC-Editor input.
 
 
 FWIW, the document allows the RFC editor  some headway in maintaining the 
 language in the style guide.
 
 --Olaf
 
 [top-post, full context below.]
 
 
 
 
 
 On Dec 22, 2009, at 10:26 AM, Julian Reschke wrote:
 
 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 
 http://tools.ietf.org/html/draft-reschke-hab-01, in particular 
 http://tools.ietf.org/html/draft-reschke-hab-01#appendix-A.1 (change 
 list) and http://tools.ietf.org/rfcdiff?url2=draft-reschke-hab-01.txt 
 (diffs).
 ...
 I just heard that the RFC 5741-to-be is not going to be fixed with 
 respect to the stutter in the boilerplate, such as in:

 -- snip --
 3.1.6.2. Text of 'Status Of This Memo'


This document is not an Internet Standards Track specification; it is
published for the historical record.

This document defines a Historic Document for the Internet community.
This document is a product of the Internet Engineering Task Force
(IETF).  It has been approved for publication by the Internet
Engineering Steering Group (IESG).  Not all documents approved by the
IESG are candidate for any level of Internet Standards; see Section 2
of RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc.
 -- snip --

 (see http://tools.ietf.org/html/draft-reschke-hab-01#section-3.1.6.2).

 This problem was reported over three weeks ago. Are we really incapable 
 to fix something simple like that within three weeks?


 Best regards, Julian
 ___
 rfc-interest mailing list
 rfc-inter...@rfc-editor.org
 http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
 
  
 
 Olaf M. KolkmanNLnet Labs
Science Park 140, 
 http://www.nlnetlabs.nl/   1098 XG Amsterdam
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf
 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Russ Housley

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 interpretation to mean that the RFC 
Editor can, on
their own initiative, fix the problem(s) that Julan has raised and 
that it does

not require changes to the about-to-be-published document.

Is that correct?  Do others agree?  (I hope so.)

d/

On 12/22/2009 11:23 AM, Brian E Carpenter wrote:
 FWIW, the document allows the RFC editor  some headway in 
maintaining the language in the style guide.

...
 For now, there are indeed weasel words such as:
However, this is not
 intended to specify a single, static format.  Details of formatting
 are decided by the RFC Editor.

These paragraphs will need to be
 defined and maintained as part of RFC stream definitions.  Initial
 text, for current streams, is provided below.

 I think this gives the RSE, in conjunction with the tools maintainers,
 reasonable flexibility.



--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
rfc-interest mailing list
rfc-inter...@rfc-editor.org
http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Bob Hinden

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/mailman/listinfo/ietf


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

2009-12-22 Thread SM

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);

   2.  to define the special considerations of a single name SINK.ARPA,
   a name which is defined never to exist (see Section 2);

   3.  to allow the procedures by which the ARPA zone is maintained, as
   documented in [RFC3172], to be modified for names present in the
   ARPA Reserved Names registry according to the special
   characteristics of those names (see Section 5).

Which of those three purposes are you suggesting the AS112 project 
could help with?


None of the above.  I said The operational utility could be 
addressed by a project similar to AS112 [1].


Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg59778.html 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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

2009-12-22 Thread Jari Arkko

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/ietf


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

2009-12-22 Thread John C Klensin


--On Tuesday, December 22, 2009 08:55 -0800 Ted Hardie
ted.i...@gmail.com 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 of the examples by clarifying that they
 indicate potential future lines of exploration rather than
 worked updates to the relevant standards also works for me.

Agreed.

 If we want to explore
 the idea in a .bogus.arpa subdomain rather than using
 sink.arpa, I don't think that's a big deal one way or the
other.

I guess the issue for me is that I want to see either 

(i) Exactly one name allocated, with no hand waving
about registries and other, similar names.  In other
words, if someone later wants another
allocated-but-not-delegated name, they go through
exactly the same process as for this one, with the added
obligation of having to justify another one to the
community.

(ii) A subtree delegation and setup, with a registry,
but with the entries in that registry applying at the
third level (e.g., sink.bogus.arpa.) and not as
immediate subdomains of .ARPA.
 
 The real question for me is how do we get off the
 chicken-and-egg problem? If we have no document specifying the
 behavior of a guaranteed non-existent name, it is hard to get
 much actual deployment and experience, and I think that's what
 is required here.  We may well find that this works in some
 contexts and fails utterly in others, based on the silly
 domain name tricks pulled on a per-application basis.  But we
 can't find that out easily without an agreed upon way of
 trying this.
 
 Maybe that makes this an experiment; maybe it makes it a
 likely-to-be-ephemeral best current practice.  But it does get
 the egg hatched, and that seems to be useful to me.

I'm ok with this, but it seems to me that the document now does
two things.  One is to set up the experiment (or possibly
long-term arrangement) that you describe above.  Another is to
set up a registry that would make little sense unless it had
multiple names in it and a mechanism for populating that
registry.  I'd like to either separate the two, move the
registry down a level in the DNS, or both.

john


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Document Action: 'EAP Authentication Using Only A Password' to Informational RFC

2009-12-22 Thread The IESG
The IESG has approved the following document:

- 'EAP Authentication Using Only A Password '
   draft-harkins-emu-eap-pwd-12.txt as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-12.txt

Technical Summary

   This memo describes an Extensible Authentication Protocol (EAP)
   method, EAP-pwd, which uses a shared password for authentication.
   The password may be a low-entropy one and may be drawn from some set
   of possible passwords, like a dictionary, which is available to an
   attacker.

Working Group Summary

   This memo is not the product of any working group.  It has been
   reviewed by several interested parties with relevant background.

Document Quality

   This memo was reviewed by Russ Housley for the IESG.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


WG Review: Internationalized Resource Identifiers (iri)

2009-12-22 Thread IESG Secretary
A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list (i...@ietf.org) by January 12,
2010.

Internationalized Resource Identifiers (iri)
---
Last Modified: 12-12-2009

Current Status: Proposed Working Group 
 
Chair(s):
TBD

Applications Area Director(s):
Lisa Dusseault lisa.dussea...@gmail.com
Alexey Melnikov alexey.melni...@isode.com

Applications Area Advisor:
Alexey Melnikov alexey.melni...@isode.com

Mailing Lists:
TBD

Description of Working Group:

This working group will produce
* A new version of RFC 3987: Internationalized Resource
Identifiers (IRIs) using draft-duerst-iri-bis as the base
* A new version of RFC 4395: Guidelines and Registration
Procedures for New URI Schemes

The new version of RFC 3987 may be split into separate documents,
if, in the opinion of the chair(s), it would facilitate distribution
of the workload and allow more focused reviews. For example, the
following breakdown has been suggested:

* Handling of Internationalized domain names in IRIs (BCP)
* Internationalization Considerations in IRIs (guidelines
for BIDI, character ranges to avoid, special considerations) (BCP)
* Syntax, parsing, comparison of IRIs (Standards track)

The working group starts with a relatively mature update to
RFC 3987 in preparation; the primary focus of the group
is to resolve conflicting uses, requirements and best practices
for internationalized URLs/URIs/IRIs and various other forms,
among many specifications and committees, while moving toward
consistent use of IRIs among the wide range of Internet
applications that use them. In particular:

* The IRI specification(s) must (continue to) be suitable
for normative reference with Web and XML standards from W3C
specifications. The group should coordinate with the W3C working
groups on HTML5, XML Core, and Internationalization, as well
as with IETF HTTPBIS WG to ensure acceptability.
* The IRI specification(s) should be follow best practices
for domain names. The group should coordinate with the IETF
IDNABIS working group and Unicode Consortium to assure acceptability.
* Explicit review by experts on (and native speakers) of RTL
languages, of the recommendations for BIDI languages,
is required.

The Working Group will examine at least one and possibly more
URI/IRI schemes to check that the new specification(s) are
appropriate for existing schemes. Schemes suggested for
review include http:, pop:, imap:, xmpp:, mailto:, and sip:.

Changes to RFC 3986 (Uniform Resource Identifier (URI):
Generic Syntax) are explicitly out of scope of this charter,
and may only be considered with a charter update.

Goals and Milestones:

January 2010 Additional update of Internet drafts by editor(s)
February 2010 Review of Internet Drafts, directions during W3C and IETF
May 2010 Working group Last Call of all documents
June 2010 Publish IRI documents as RFCs (BCP, standards track, as 
appropriate)
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


WG Review: Messaging Abuse Reporting Format (marf)

2009-12-22 Thread IESG Secretary
A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list (i...@ietf.org) by January 12,
2010.

Messaging Abuse Reporting Format (marf)
---
Last Modified: 12-21-2009

Current Status: Proposed Working Group 

Chair(s):
TBD

Applications Area Director(s):
Lisa Dusseault lisa.dussea...@gmail.com
Alexey Melnikov alexey.melni...@isode.com

Applications Area Advisor:
Alexey Melnikov alexey.melni...@isode.com

Mailing Lists:
General Discussion: abuse-feedback-rep...@mipassoc.org
To Subscribe: 
http://mipassoc.org/mailman/listinfo/abuse-feedback-report
Archive: http://mipassoc.org/mailman/listinfo/abuse-feedback-report

Description of Working Group:
Messaging anti-abuse operations between independent services often 
requires sending reports on observed fraud, spam virus or other abuse 
activity. A standardized report format enables automated processing. The
Abuse 
Reporting Format (ARF) specification has gained sufficient popularity to 
warrant formal codification, to ensure and encourage future
interoperability with new
implementations. The primary function of this working group will be 
to solicit review and refinement of the existing specification.

ARF was developed by a messaging trade organization independent of 
the IETF, and uses a format similar to a Delivery Status Notification
(DSN, 
RFC3464) to report fraud, spam, viruses or other abusive activity in the 
email system.  The basic format is amenable to processing by humans or
software, 
with the latter requiring the format to be standardized, to permit 
interoperability between automated services, particularly without prior
arrangement.

ARF as initially defined is already in widespread use at large ISPs, so
interoperability can be demonstrated. Some tools already exist
for processing ARF messages, a few of which are open source. In 
order to preserve the installed base, the working group will make the
minimum 
changes necessary to the existing specification and will seek to have
backward
compatibility. Furthermore, some extensions to the current proposal are
of interest to the community, such as the means for an operator to 
advertise an email address to which abuse reports using ARF should be
sent. The
working group will take on the task of considering and specifying 
such a mechanism.

The initial proposal is published as draft-shafranovich-feedback-report,
and this will provide the working group's starting point.

The working group should consider such factors as:
* implementer experience
* ability to achieve broad implementation and interoperability
* existing uses of ARF
* internationalization
* ability to address broader use cases than may have be contemplated 
by the original authors
* overlap with the INCH working group's work (e.g. RFC5070); it is 
unclear whether
such overlap is appropriate or should be avoided

Thus, the working group's specific tasks are as follows:

1) The group will first produce a Proposed Standard track specification
of ARF.  This will document current use, removing any portions that are 
not implemented and/or
not required for a minimum implementation (to be published later as
extensions).
This will include not only the format of an ARF message, but must also
include appropriate documentation of security considerations and creation
of IANA registries for elements of ARF to support future extensions, as
well as informational sections conveying current best practices.

2) The group will specify the integration of ARF into DKIM DNS key
records, with draft-kucherawy-dkim-reporting as its input. It contains
extensions to DKIM that are related to ARF as a means of reporting
DKIM-related failures which include phishing (fraud) and as such are
relevant to the ARF effort.  The group will produce Proposed Standard
track specification for these ARF and DKIM extensions.

3) The group will finally consider a means for publishing the address to
which ARF reports should be sent. Not all ARF participants wish to use
abuse@(domain), which is the current standard (RFC2142) , as the place to
send automated ARF-formatted reports. The group will either conclude that
the industry should continue to use this de facto standard (and thus no
specification is appropriate), or will produce a Proposed Standard track
document identifying the means by which that address should be advertised.


The group may consider re-chartering to cover related work, such as
further extensions, once these deliverables have been achieved.

The working group is aware of a related activity in another group:

- Open Mobile Alliance http://www.openmobilealliance.org/ SpamRep

The goal is to coordinate efforts with this group as required.

Goals and Milestones:
Jan 2010 Issue first WG-based Internet-Draft defining ARF
Mar 2010 

Protocol Action: 'IMAP4 Keyword Registry' to Proposed Standard

2009-12-22 Thread The IESG
The IESG has approved the following document:

- 'IMAP4 Keyword Registry '
   draft-melnikov-imap-keywords-10.txt as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-keywords-10.txt

Technical Summary

Over the years, some IMAP keywords (client-defined flags) have become
de-facto standard, with some specific semantics associated with them.
In some cases, different client implementors have defined and used
keywords with different names, but the same semantics.  Some server
implementors decided to map such keywords to each other automatically
in order to improve cross client interoperability.  In other cases,
the same keywords have been used with different semantics, causing
interoperability problems.

This document attempts to prevent further incompatible uses of IMAP
keywords by establishing an IANA registry for IMAP keywords, and by
allocating a special prefix for standardized keywords.

Working Group Summary

Nothing to note.  This is a pretty straightforward creation of an IANA
registry.

Document Quality

The registry is seeded with some keywords that are already in use in
existing implementations.  Experts to be Arnt Gulbrandsen and Dave
Cridland (dave.cridl...@isode.com and a...@oryx.com)

RFC Editor Note

Note cross client in section 2 (across a line break) should be
cross-client.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


WG Action: Multiple AoR reachabiliTy InformatioN Indication (martini)

2009-12-22 Thread IESG Secretary
A new IETF working group has been formed in the Real-time Applications and
Infrastructure Area.  For additional information, please contact the Area
Directors or the WG Chairs.

Multiple AoR reachabiliTy InformatioN Indication (MARTINI)
-
Last Modified: 2009-12-08

Proposed Chair(s):
Spencer Dawkins spen...@wonderhamster.org
Bernard Aboba bernard_ab...@hotmail.com

Real-time Applications and Infrastructure Area Director(s):
Robert Sparks rjspa...@nostrum.com
Cullen Jennings flu...@cisco.com

Real-time Applications and Infrastructure Area Advisor:
Cullen Jennings flu...@cisco.com

Technical Advisor(s):

Mailing Lists:
General Discussion: mart...@ietf.org
To Subscribe: martini-requ...@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/martini/index.html

Description of Working Group

The MARTINI working group is chartered to specify a means by which an
entity that is authoritative for SIP URIs can dynamically register
reachability information for multiple Addresses of Record (AORs) with a
service provider.

The SIP protocol [RFC 3261 and its extensions] supports multiple means of
obtaining the connection information necessary to deliver out-of-dialog
SIP requests to their intended targets. When a SIP Proxy needs to send a
request to a target AOR within its domain, it can use a location
service to obtain the registered contact URI, together with any associated
path information [RFC 3327], and build a route set to reach the target
UA(s). The SIP REGISTER method can be used to register contact URIs and
path information. SIP-outbound [RFC 5626] enhances this mechanism to cater
for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a
request to a target for which it is not authoritative, the UA/Proxy can
use RFC3263 procedures for using DNS to resolve the next-hop connection
information.

In practice, many small and medium-sized businesses use a SIP-PBX that is
authoritative for tens or hundreds of SIP AoRs. This SIP-PBX acts as a
registrar/proxy for these AoRs for clients hosted by the SIP-PBX. UAs
register with the SIP-PBX on behalf of the AoRs concerned. A SIP Service
Provider (SSP) provides SIP peering/trunking capability to the SIP PBX.
The SIP-PBX must be reachable from the SSP so that the SSP can route
inbound SIP requests for the AoRs addressed to the SIP PBX, routing these
requests to the SIP-PBX itself for onward delivery to registered UAs.

Experience has shown that existing mechanisms are not always sufficient
to
support SIP-PBXs for small/medium businesses. Since a single SSP may
support multiple thousands of such SMB SIP-PBX's, it is impractical and
cost-prohibitive to manually provision their IP addresses in every SIP
node along paths to those SIP-PBXs. Furthermore, IP addresses can be
dynamically assigned and therefore can potentially change relatively
frequently.

In current deployments, dynamic reachability mechanisms based on the SIP
REGISTER method are commonly used. Effectively, a single REGISTER request
registers the AoR of the SIP-PBX, so that any out-of-dialog request
targeted at a SIP URI for which the SIP-PBX is authoritative can be
delivered from the SSP to the SIP-PBX.  However, implementations of this
mechanism vary in details, leading to interoperability issues between
SIP-PBXs and SSPs, and the need for equipment to support different
variants.

The task of this working group is to to standardize a multiple-AoR
registration mechanism for SIP that can be widely deployed by service
providers at large scale. The solution will support AoRs with E.164
addresses at a minimum, although support for other classes of AoRs may be
included.

The solution will utilize existing SIP mechanisms to the extent possible,
although it is anticipated that small protocol extensions are likely to be
required, and hence a standards track (rather than BCP) deliverable is
expected. The solution will accommodate existing SIP extensions relating
to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by
ensuring that they are not precluded from use in the context of multiple
AoR registrations. The solution will incorporate a compatibility mechanism
to ensure a deterministic outcome when interworking with entities that do
not support multiple AoR registration.

The working group will coordinate with SIP Forum and other industry
groups
on requirements and will coordinate its work with other IETF working
groups including DRINKS and SIPCORE.

Goals and Milestones
Dec 2009 Solicit solution-space drafts
Jan 2010 Interim meeting
Jan 2010 Adopt Working Group draft
Feb 2010 First Working Group Last Call
Mar 2010 Second Working Group Last Call
Apr 2010 Multiple AoR Registration specification to IESG (PS)
Jul 2010 Close or recharter working group
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Last Call: draft-ietf-6man-iana-routing-header (IANA Allocation Guidelines for the IPv6 Routing Header) to Proposed Standard

2009-12-22 Thread The IESG
The IESG has received a request from the IPv6 Maintenance WG (6man) to 
consider the following document:

- 'IANA Allocation Guidelines for the IPv6 Routing Header '
   draft-ietf-6man-iana-routing-header-00.txt as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
i...@ietf.org mailing lists by 2010-01-12. Exceptionally, 
comments may be sent to i...@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-6man-iana-routing-header-00.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19120rfc_flag=0

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


MARTINI Virtual Interim Meeting

2009-12-22 Thread IESG Secretary
What: MARTINI Virtual Interim Meeting

January 7, 2010 from 11 AM - 1 PM Pacific Time

Topics:

- Discussions of currently deployed mechanisms for multiple AOR
registration, and their pros and cons

- Drafts describing solutions that (hopefully) improve upon existing
deployed mechanisms

Logistics: we'll request WebEx, so please watch the MARTINI mailing list
at
http://www.ietf.org/mail-archive/web/martini/current/maillist.html for
logistic details
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce