Subject: [spfbis] Issue: Processing limits needs clarification and reorganization

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Feb 2012 12:52:05 -0500

As I understand it, security considerations aren't generally supposed to give 
normative protocol implementations constraints, but the processing limits in 
paragraph 10.1 of RFC 4408 does exactly this.

While the technical limits themselves are appropriate, paragraph 10.1 should 
be split into two parts.  The actual processing limits should find a home in 
the main body of the specification and then a revised security consideration 
should focus on a clearer discussion about why they are important and why one 
should design records the minimize DNS impact.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 06 Feb 2012 10:22:04 -0800

> should design records the minimize DNS impact.

+1

There are some (security and other) folks who believe that it is entirely 
acceptable to have normative statements in the security considerations section.

I'm not one of them.  I think that a Considerations section is an adjunct to the 
actual specification and that format, protocol, configuration and operations 
normative statements should be in "specification" sections, distinct from 
analysis and 'considerations' section.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Feb 2012 10:28:36 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Monday, February 06, 2012 10:22 AM
> To: Scott Kitterman
> Cc: [email-masked]
> Subject: Re: [spfbis] Issue: Processing limits needs clarification and reorganization
> 
> +1
> 
> There are some (security and other) folks who believe that it is
> entirely acceptable to have normative statements in the security
> considerations section.

+1 as well, both to the procedural point and to the specific issue that needs clarification.

---

From: Hector Santos <[email-masked]>
Date: Mon, 06 Feb 2012 23:35:24 -0500

> should design records the minimize DNS impact.

Sounds like material for a BCP.  There is also the difference between 
security concerns and optimization concerns.

However, if anything, there is a generalize guideline for DNS 
operators to define optimal SPF records where the intent is minimize 
any overhead.   For example, a classic example is one like gmail.com 
which is currently prepared for at least two (2) lookups since the 
first query result is an instruction to perform a redirect:

          v=spf1 redirect=_spf.google.com

With the volume of inbound gmail.com out there, can you imagine the 
immediate 1/2 reduction of DNS query overhead if the gmail folks 
changed it to a direct/single call?

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: S Moonesamy <[email-masked]>
Date: Tue, 07 Feb 2012 03:28:22 -0800

At 08:35 PM 2/6/2012, Hector Santos wrote:
>Sounds like material for a BCP.  There is also the difference 
>between security concerns and optimization concerns.

I'll say it again.  I don't see anything wrong about the comment.

Please do not comment on issues.  There will be ample opportunity for 
comments in a couple of weeks.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Tue, 07 Feb 2012 10:00:53 -0500

> comments in a couple of weeks.

Not quite following. Including with your previous similar post, you 
seem to be providing the idea (all) posted "Issue" comments are being 
cataloged and will posted again later (by you) for RFC?

---

From: S Moonesamy <[email-masked]>
Date: Tue, 07 Feb 2012 08:05:37 -0800

Hi Hector,
At 07:00 AM 2/7/2012, Hector Santos wrote:
>seem to be providing the idea (all) posted "Issue" comments are 
>being cataloged and will posted again later (by you) for RFC?

The WG Chairs asked for reviews of RFC 4408.  The issues identified 
in the reviews will be listed in the issue tracker.  We will then 
request the working group to comment on each issue.  Please note that 
the WG Chairs have not made any determination about whether an issue 
is valid or not valid or what is in scope.

If you have any questions above the above, feel free to send them to 
the list or to the WG co-chairs.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Feb 2012 11:19:15 -0500

> being cataloged and will posted again later (by you) for RFC?

Yes.  We're treating the "Issue" comments as part of the reviews I
asked for last Friday.  When I posted that, I explicitly asked that
people not debate or discuss the reviews, but simply post their own
reviews.  SM and I will collate things into issues in the WG's issue
tracker, once that's up.

We're trying to break down the effort here into minimal steps, and
avoid going over the same ground repeatedly in the WG.  We thought a
good way to do this would be to get all the issues identified, and
then we could put together the full list of issues to be tackled by
the WG.  By isolating issues this way, we can concentrate our
attention on one or two controversies at a time, instead of trying to
argue about everything at once.  The goal is to make progress on our
nicely (and strictly) limited charter.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Tue, 07 Feb 2012 11:29:57 -0500

S Moonesamy wrote:
> The WG Chairs asked for reviews of RFC 4408.  The issues identified in 
> the reviews will be listed in the issue tracker.  We will then request 
> the working group to comment on each issue.  Please note that the WG 
> Chairs have not made any determination about whether an issue is valid 
> or not valid or what is in scope.
> 
> If you have any questions above the above, feel free to send them to the 
> list or to the WG co-chairs.

The concern was whether the preponderance of ignorance has already 
starting or the issues posted were automatically added to the tracker 
(wasn't even aware this was going to be done now) without the WG 
chair(s) judgment to catalog it or not.  I see you made a statement 
that its your call what gets on the table. It would be nice to get an 
early notification that a issue is cataloged or will not for XYZ 
reason.  I just don't want to wasting time to posting issues believing 
it will be cataloged and in the end, find out, a) issues weren't 
cataloged and/or b) ignored and never comes up again (in two weeks) 
and I feel there is a need to create more noise by reposting it again.

If noise reduction is desired, feedback is useful.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 07 Feb 2012 09:24:26 -0800

Hi Hector,
At 08:29 AM 2/7/2012, Hector Santos wrote:
>starting or the issues posted were automatically added to the 
>tracker (wasn't even aware this was going to be done now) without 
>the WG chair(s) judgment to catalog it or not.  I see you made a 
>statement that its your call what gets on the table. It would be 
>nice to get an early notification that a issue is cataloged or will 
>not for XYZ reason.  I just don't want to wasting time to posting 
>issues believing it will be cataloged and in the end, find out, a) 
>issues weren't cataloged and/or b) ignored and never comes up again 
>(in two weeks) and I feel there is a need to create more noise by 
>reposting it again.

As I mentioned previously, the WG Chairs have not made any 
determination about whether an issue is valid or not valid or what is 
in scope ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00336.html 
).  Someone will have to make the call.  That someone is generally 
the WG Chairs.  I am waiting for the issue tracker to be accessible 
to "catalog" the issues.  May I humbly suggest that you wait a little 
before determining whether the WG Chairs have provided ample 
opportunity for discussion about every issue which have been posted?

Regards,
S. Moonesamy
SPFBIS WG co-chair