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

"Haleplidis Evangelos" <> Mon, 03 August 2015 22:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 445F11B31CA; Mon, 3 Aug 2015 15:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2gavxCYTBhxD; Mon, 3 Aug 2015 15:17:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B16B61A00E3; Mon, 3 Aug 2015 15:17:09 -0700 (PDT)
Received: by wicgj17 with SMTP id gj17so124594359wic.1; Mon, 03 Aug 2015 15:17:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=zu7TdsUokJGK6CPEFXaxLeuy6hHJEup8kIkVSFt6Ne4=; b=b2EecDaJAci1kI7rraFYbalWYHpeqkhWZTqmgRoIhi3dkfWz0DefTYO+9yiQzCjHNf aiwcDCGds6ZRu0nPx4PaYalc7PnSmWwnjiZTdpVcuY6l7mlKFrLPErGKLlnreJPgU4EJ /g8/pDw/TV+ixBC0egnm/8xRgAKaV/E4EyVeKqBwDxsVnsTxrk07AvdJxIU9foDPDuW8 vWOht7qeAyBEhi2iz4279uHwbJe4Yg1IfNvSkmxBgcSMv0N02yv7GqLOL+bsHyGBdQsJ XA+4ufyuPQ3cgiUkmrBBMAEDSM6vV6+G92A2TNHoFWDaYSubztEbfX3aNCopRdx7hram rDmw==
X-Received: by with SMTP id r8mr856893wif.13.1438640228366; Mon, 03 Aug 2015 15:17:08 -0700 (PDT)
Received: from EhalepXPS ( []) by with ESMTPSA id ft5sm15638406wib.4.2015. (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Aug 2015 15:17:07 -0700 (PDT)
From: Haleplidis Evangelos <>
To: 'Alia Atlas' <>,,
References: <>
In-Reply-To: <>
Date: Tue, 04 Aug 2015 01:17:05 +0300
Message-ID: <010501d0ce3a$2211c7c0$66355740$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01D0CE53.475EFFC0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdDLybpo5ASamEFGTOCbYyohASIHVgCcB4yg
Content-Language: el
Archived-At: <>
Cc: "'Joel M. Halpern'" <>
Subject: Re: [forces] AD review of draft-ietf-forces-lfb-subsidiary-management-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ForCES WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Aug 2015 22:17:12 -0000

Greetings Alia,


Thank you very much for your review.

Please see inline.





From: forces [] On Behalf Of Alia Atlas
Sent: Friday, July 31, 2015 10:47 PM
Cc: Joel M. Halpern
Subject: [forces] AD review of draft-ietf-forces-lfb-subsidiary-management-01


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.

[ΕΗ] Yes. These parameters are placeholders for future use, in order not to redefine the LFB class versions. These are simple strings that define either the attribute names, and the parameters. These should be read by the CE to know what kind of attributes and parameters it can safely use. If this is ok, we’ll try to add such text in the document.

2) In Sec. 4.2, could you please provide a reference to the syslog severity levels?  For instance, the IANA registry ( ) and/or RFC 3164 would be lovely.  

[ΕΗ] Thank you. We’ll certainly add the references.

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.  


[ΕΗ] The CE that creates these connections could either be:

A.      The FE manager which is the one responsible for creating these connections, therefore the FE should trust it.

B.      An already associated and trusted CE.

This document has no effect on the ForCES protocol security. Therefore, as the CE in question is already the master it should be trusted to create the connections. Such security issues should concern the CE. If the CE is faulty, rogue or hacked, there is no way for the FE to know and will perform any action that the CE requests.


We can add this text (or something very similar) to the Security considerations.