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

From: "Haleplidis Evangelos" <[email-masked]>
Date: Tue, 4 Aug 2015 01:17:05 +0300

Greetings Alia,

Thank you very much for your review.

Please see inline.

Regards,

Evangelos.

From: forces [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Friday, July 31, 2015 10:47 PM
To: [email-masked]; [email-masked]
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 (http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-2 ) 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.

Thanks,

Alia