[forces] AD review of draft-ietf-forces-lfb-subsidiary-management-01

Alia Atlas <akatlas@gmail.com> Fri, 31 July 2015 19:47 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: forces@ietfa.amsl.com
Delivered-To: forces@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6921E1A9045; Fri, 31 Jul 2015 12:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 P4dDEs2zXJcv; Fri, 31 Jul 2015 12:47:21 -0700 (PDT)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2EE1A8BB2; Fri, 31 Jul 2015 12:47:18 -0700 (PDT)
Received: by obbop1 with SMTP id op1so61544333obb.2; Fri, 31 Jul 2015 12:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=S3y+z2svjk1iVLg7FLLntafhdOeWZMEyzjjC2RQAGWI=; b=teaCXceJuQzpcIYldmkj3yheiZcJctIbzc0W7UQ0qSExerCTTjfi3AM9zERb/0hPKb 3ORK24In6X1ZQl52ogwYTvl05X/kt/jKXTa9wsoMZQF6VTPmTD4tIFTXJXQtEs9VWsZA azfrmFXcNcM8DSdShUDVBNVwsnzGhhPokEhL8+ENvhMEjaSnf10TuErE/CllrtcAq9BJ 7Ks+mrccDs3BWIfI2TGwOKrx9DB3aw/NAhw1qRQbIebq5AqW/xiaY29t3eHmGnJgh2RD 7YDdnmFNT51fZE5Te9P7BQavV6LZZvhljtehJQPPVULVR9X8N04a618ju9emFWFLhstW cJeA==
MIME-Version: 1.0
X-Received: by 10.60.45.104 with SMTP id l8mr5463473oem.61.1438372038292; Fri, 31 Jul 2015 12:47:18 -0700 (PDT)
Received: by 10.60.41.99 with HTTP; Fri, 31 Jul 2015 12:47:18 -0700 (PDT)
Date: Fri, 31 Jul 2015 15:47:18 -0400
Message-ID: <CAG4d1rcYBcXmV1unH-DW5cmmvFS8OLFg09La4Vd8QUBYc9gxkg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: draft-ietf-forces-lfb-subsidiary-management@ietf.org, "forces@ietf.org" <forces@ietf.org>
Content-Type: multipart/alternative; boundary=089e0149ce3865b960051c31161e
Archived-At: <http://mailarchive.ietf.org/arch/msg/forces/2bIkx6W6ks5nHP4OiIyw8mWIJco>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: [forces] AD review of draft-ietf-forces-lfb-subsidiary-management-01
X-BeenThere: forces@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ForCES WG mailing list <forces.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/forces>, <mailto:forces-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/forces/>
List-Post: <mailto:forces@ietf.org>
List-Help: <mailto:forces-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/forces>, <mailto:forces-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2015 19:47:23 -0000

Hi Bhumip, Evangelos, and Jamal,

Thanks for your work on this draft. As is customary, I have done my AD
review of the draft before asking that it go forward to IETF Last Call.

I have only a few quibbles, so I have advanced this to IETF Last Call.  It
is on the IESG telechat on Sept 3.    Please do respond and update the
draft during IETF Last Call.  As you well know, having authors who are
extremely responsive helps greatly with getting these final steps done.

Minor quibbles:

1) In Sec. 4.4.3, two of the capabilities are described as placeholders.
Can you please clarify what the expected standardized behavior is?  I
imagine that the capabilities are filled out as described - though with
unstandardized information.

2) In Sec. 4.2, could you please provide a reference to the syslog severity
levels?  For instance, the IANA registry (
http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-2
) and/or RFC 3164 would be lovely.

3) In the Security Considerations section, a few words about why it is ok
to trust a CE to create a connection to another CE would be useful.

Thanks,
Alia