Subject: Re: [spfbis] #48: Section 8.1 - macro defs

From: S Moonesamy <[email-masked]>
Date: Tue, 28 Aug 2012 22:49:48 -0700

At 18:29 26-08-2012, spfbis issue tracker wrote:
>#48: Section 8.1 - macro defs
>
>  Message posted by Arthur Thisell on 26 Aug 2012:
>
>  in section 8.1 (macro defs), there is a "Note: Care MUST be taken so that
>  ...".  I think it should be clearer that it is the ADMD, not the SPF
>  verifier that needs to take care.  That is, it should say "Note: The ADMD
>  needs to take care so that..."  This wording also fixes what I think was
>  an incorrect changing of an english language meaning of "must" to a RFC
>  2119 keyword.
>
>  in section 8.1 (macro defs), there is a note that says "Note: Domains
>  SHOULD avoid using ...".  Again, if RFC 4408 the "should" was lower case
>  and I don't think it was meant to be an RFC 2119 keyword.  Maybe "Note:
>  ADMDs are discouraged from using ..."?
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html

Section 8.1 has not received adequate review.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 29 Aug 2012 23:46:58 -0400

> >  http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html

I need to do a general review of the capitalization changes as I agree I was 
too liberal with adding them.  This may not end up being one of those cases.  
Depending on how issue #22 gets resolved, label too long could explicitly be a 
permerror limit (some implementations treat it that way already - #22 is about 
resolving an ambiguity in 4408) and in that case, this limit would be a hard 
limit for records/macro construct development and the MUST would be 
appropriate.  Given that we have to at least give a nod to the fact that this 
causes permerrors with some implementations, I think the least this should end 
up being is a SHOULD, but once we get #22 sorted we should consider it.  I'd 
proposed adding this to #22 and closing this issue.

> Section 8.1 has not received adequate review.

Since you've recently stated on the list that you haven't reviewed the 
document yet, perhaps you could provide that.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 29 Aug 2012 22:03:36 -0700

Hi Scott,
>too liberal with adding them.  This may not end up being one of those cases.

You could get back to it for Issue #36.

>proposed adding this to #22 and closing this issue.

There hasn't been any comments about Issue #22.  Could WG 
participants please review the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02277.html and 
comment on that thread?

>document yet, perhaps you could provide that.

I will have to review the draft after the WGLC.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 08:13:38 -0500

>At 20:46 29-08-2012, Scott Kitterman wrote:
...
>I will have to review the draft after the WGLC.

So? If you defer review until after WGLC, then we may end up with a lot of new issues that need to be addressed late in the process.  As efficient as that may be for you,  it seems highly suboptimal for the goal of finishing the work of the group in a timely manner.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Thu, 30 Aug 2012 07:47:11 -0700

At 06:13 30-08-2012, Scott Kitterman wrote:
>So? If you defer review until after WGLC, then we may end up with a 
>lot of new issues that need to be addressed late in the process.  As 
>efficient as that may be for you,  it seems highly suboptimal for 
>the goal of finishing the work of the group in a timely manner.

The WG can end up with a lot of new issues after the WGLC.  The goal 
is for the WG to complete the work in a timely manner.  This entails 
getting timely reviews, identifying issues and addressing them.  A 
lot of what I do is not efficient for me.  I have commented on what 
could become an issue later in the process.  The bottom line is that 
it is up to WG participants to do the work.

This WG took on the task to write a Proposed Standard.  It is 
expected that the WG has the expertise to do the work and it will act 
in a responsible manner.  I understand that the work is not easy.  I 
understand that there can be disagreements.  That's part of the work 
whether I like it or not.

Regards,
S. Moonesamy