Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00

"Murray S. Kucherawy" <superuser@gmail.com> Tue, 07 May 2013 22:35 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664D521F86E4 for <apps-discuss@ietfa.amsl.com>; Tue, 7 May 2013 15:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksTtS4dg5tSF for <apps-discuss@ietfa.amsl.com>; Tue, 7 May 2013 15:35:45 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1FA21F86D5 for <apps-discuss@ietf.org>; Tue, 7 May 2013 15:35:45 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id j13so1172010wgh.28 for <apps-discuss@ietf.org>; Tue, 07 May 2013 15:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=70d2CjfTp/qMfsN3lB54RBaIUGrXVU00SbRz1z/P0fY=; b=ToGMG4zjzNg3uXW8xLJe8hIGl4JpgB2rWCDNjusYODM4wTZrCc5jyxPSv6mAoCUvFj j9GuoAnoSho2TZUbmNNrtBowczLwGV1S2CQ1+14vIoE8fsqXaYyEhYa8hAk7kUL1iYmP AE2mcVnpGPF7qo+lMmW+PDmBhZM/Fyo1NDngiccCV5B33XOWWPMlOspLIOXg6pgSShuI ABUG1chFuX4oeRwu9MUbYFWR+311ica0yRd3pxnwyfv79v44PVZyieFFf0mKLu1nrZyO hiyI+ggM4y+jHR8IW6PvAJIoL52/te4wMg6j7IMenhO2J+5RUU39yOBgkhbmGPxCtrSJ OVew==
MIME-Version: 1.0
X-Received: by 10.180.14.5 with SMTP id l5mr17575834wic.32.1367966144343; Tue, 07 May 2013 15:35:44 -0700 (PDT)
Received: by 10.180.14.34 with HTTP; Tue, 7 May 2013 15:35:44 -0700 (PDT)
In-Reply-To: <518920D0.1040705@tana.it>
References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> <CAL0qLwaMWbLbgAquXXnC1a_CRgu4zUgHwykc71_on2-99eAxww@mail.gmail.com> <518920D0.1040705@tana.it>
Date: Tue, 7 May 2013 15:35:44 -0700
Message-ID: <CAL0qLwbMQ4QfmgQ0VAX+ajXvgp8DK1AcV5x1dQJacD9BEbUyxQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Content-Type: multipart/alternative; boundary=f46d040fa04c19330a04dc287042
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2013 22:35:46 -0000

On Tue, May 7, 2013 at 8:42 AM, Alessandro Vesely <vesely@tana.it> wrote:

> >>    This is similar in syntax to a fully-qualified domain name.
> >
> > You're aware of how this works; what would you suggest?  The ABNF is
> > "value" because it is usually an FQDN, but we also say that it doesn't
> have
> > to be.
>
> I cannot think of anything but saying that explicitly.  How about
> merging the first two paragraphs?  E.g.:
>
>    Every Authentication-Results header field has an authentication
>    service identifier field ("authserv-id" above).  This refers to
>    the authenticating service within a given ADMD.  For example, if
>    the identifier is similar in syntax to a fully-qualified domain
>    name, domain delegation semantics can be used to establish whether
>    it belongs to an ADMD's name space.  This specification does not
>    mandate how, but the identifier MUST correspond unequivocally to
>    the ADMD that generates it and MUST pertain to exactly that one
>    ADMD. ...
>

I'm about to post a new version with this section reworked a bit.  Let me
know what you think of it.


> >>    The uniqueness of the identifier MUST be guaranteed by the ADMD
> >>    that generates it and MUST pertain to exactly that one ADMD.
> >>
> >> What is actually required is not the "uniqueness" of the identifier,
> >> but the ability to univocally identify the responsible ADMD using the
> >> identifier.  I'd suggest to rephrase the sentence accordingly.
> >
> > Are those not synonymous?
>
> Not quite.  For example, a random number would satisfy the uniqueness
> but can hardly refer to an ADMD.
>

Sure it can; NetEase (a Chinese ESP) uses "163.com" as their domain name.
An authserv-id of just "163" would be fine.


> > From the perspective of a module consuming this field, it has to be
> > the case that such a module can safely assume that a field bearing
> > the authserv-id it expects (or one of a set, perhaps) can be
> > trusted.
>
> Right.  But then associating the field with a specific ADMD becomes
> interesting only if you happen to mix the message streams from
> multiple ADMDs (e.g. on a MUA).  In that case, /all/ ADMDs have to be
> compliant, and they have to agree on interoperable naming conventions.
>

That's actually only true if you plan to trust the A-R fields added by
other ADMDs.  Most commonly you'll only care about your own.


> >>    The "policy" result would be returned if, for example, [SPF]
> >>    returned as "pass" result, but the local policy check finds that
> >>    the sender's policy is unacceptable (e.g. terminates with "+all").
> >
> > I don't agree with including that specific example, as it encourages a
> > particular local policy debate that I don't think this document should
> > approach.
>
> I thought abhorring +all was uncontroversial.
>

Probably, but it's not something this document needs to discuss in order to
be effective.

-MSK