Re: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Fri, 24 June 2016 22:39 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0144912D5DB; Fri, 24 Jun 2016 15:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=CqpTFV9H; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=or51KA4m
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiKf2rAlQZIG; Fri, 24 Jun 2016 15:39:02 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E84A12D1A2; Fri, 24 Jun 2016 15:39:02 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 559A720C4B; Fri, 24 Jun 2016 18:39:01 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 24 Jun 2016 18:39:01 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=rGMpx1S3mqt15a4goHKCsXT9tks=; b=CqpTFV 9HYi5esw+hT6hPD19ktFy6a2PddT4eAGVb+BNMxpeYkqifpUVJ0Yhghnnn4lsgLs rPvj8XhZSyFadFbFFKnpC6YK01PBi9w7eZTgJagCTM3lgBq/ABHZF4KcXZ2izhG8 OM+s/csIjbNt6K5zQTv1qXsvEXA8s2TlXGGvE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=rGMpx1S3mqt15a4 goHKCsXT9tks=; b=or51KA4mLRNUTD3062dryAuzaGqibAV2TpytN9f13sViBXf kfiLUhqhRorV+gSs1v1GMrGnoastIzi6XcAzlAQskiOR/NA+8ORhqx13DdFWo79b tbs96q6iIAhEzm0X7fdC4NSxtNfzk6ciT8zLML1k1rHG4tITzPZDUFGL9UQU=
X-Sasl-enc: nuMlyBqOao4YtE5iV7OoIibI+9jIhXhaE5Itylf67xX8 1466807940
Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id C9A6CCCD88; Fri, 24 Jun 2016 18:39:00 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: iPad Mail (13F69)
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD976BBAE@marathon>
Date: Fri, 24 Jun 2016 23:48:42 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <6DFD8627-EDFF-43FD-8CA0-62589B6843B5@fastmail.fm>
References: <20160601073339.16171.59393.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFCD974F85C@marathon> <1464858290.1234564.625673017.7541014D@webmail.messagingengine.com> <359EC4B99E040048A7131E0F4E113AFCD97500C7@marathon> <359EC4B99E040048A7131E0F4E113AFCD976686D@marathon> <CAHbuEH54VwDJsoTFBik6Tr20WCHNgXea1DMzcHGQiBK_dMV8bA@mail.gmail.com> <1466787578.3424901.647604393.320171FC@webmail.messagingengine.com> <359EC4B99E040048A7131E0F4E113AFCD976BA0C@marathon> <359EC4B99E040048A7131E0F4E113AFCD976BBAE@marathon>
To: "Roman D. Danyliw" <rdd@cert.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/cMbutYIg2ZTeuOBuM4CEz3w1omk>
Cc: "mile-chairs@tools.ietf.org" <mile-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, "mile-chairs@ietf.org" <mile-chairs@ietf.org>, "mile@ietf.org" <mile@ietf.org>, "draft-ietf-mile-rfc5070-bis@ietf.org" <draft-ietf-mile-rfc5070-bis@ietf.org>
Subject: Re: [mile] Alexey Melnikov's Discuss on draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2016 22:39:04 -0000

Hi Roman,

> On 24 Jun 2016, at 22:06, Roman D. Danyliw <rdd@cert.org> wrote:
> 
> Hello Alexey!
> 
>> -----Original Message-----
>> From: Roman D. Danyliw [mailto:rdd@cert.org]
>> Sent: Friday, June 24, 2016 2:09 PM
>> To: Alexey Melnikov <aamelnikov@fastmail.fm>; Kathleen Moriarty
>> <kathleen.moriarty.ietf@gmail.com>
>> 
>>> -----Original Message-----
>>> From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm]
>>> Sent: Friday, June 24, 2016 1:00 PM
>>> To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Roman D.
>>> Danyliw <rdd@cert.org>
>>> Cc: mile-chairs@tools.ietf.org; takeshi_takahashi@nict.go.jp; The IESG
>>> <iesg@ietf.org>; mile-chairs@ietf.org; mile@ietf.org;
>>> draft-ietf-mile-rfc5070- bis@ietf.org
>>> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-mile-rfc5070-bis-22:
>>> (with DISCUSS and COMMENT)
>>> 
>>> Hi Kathleen/Roman,
>>> 
>>>> On Wed, Jun 22, 2016, at 08:53 PM, Kathleen Moriarty wrote:
>>>> Hi Alexey,
>>>> 
>>>> Do the recent updates address your concerns?
>>> 
>>> The latest version is an improvement.
>>> 
>>> One final point I am uncomfortable with:
>>> 
>>> 4.3.  Validation
>>> 
>>>   IODEF documents MUST be well-formed XML.  It is RECOMMENDED that
>>>   recipients validate the document against the schema described in
>>>   Section 8.  However, mere conformance to this schema is not
>>>   sufficient for a semantically valid IODEF document.  The text of
>>>   Section 3 describes further formatting and constraints; some that
>>>   cannot be conveniently encoded in the schema.  These MUST also be
>>>   considered by an IODEF implementation.  Furthermore, the enumerated
>>>   values present in this document are a static list that will be
>>>   incomplete over time as select attributes can be extended by a
>>>   corresponding IANA registry per Section 10.2.  Therefore, IODEF
>>>   implementations MUST periodically update their schema and MAY need
>> to
>>>   update their parsing algorithms to incorporate newly registered
>>>   values.
>>> 
>>> How realistic is this to require all implementations to update their
>>> schema? Is
>>> IODEFv2 intended to be used by IoT devices that might not have much
>>> battery/CPU power to do this?
>>> (I appreciate that this is different from my original DISCUSS point,
>>> but this is related to a change that was caused by my DISCUSS. So I
>>> would like to discuss this quickly.)
>> 
>> Makes sense.  What about updating the text to read: "IODEF implementation
>> SHOULD periodically ... ".
> 
> The s/MUST/SHOULD/ was made in -25.

I think this is a reasonable compromise. Thank you!