Subject: [lmap] Some comments

From: Robert Kisteleki <[email-masked]>
Date: Tue, 25 Sep 2012 17:37:52 +0200

Hi,

General comments:

Rather than saying "component X should authenticate/authorize component Y"
numerous times, and "component X should allow for optional encryption and
integrity protection" it's most likely better to say something like "all
components exchanging information should use mutually authenticated,
encrypted and integrity protected channels". That'd simplify a lot of the
requirements in section 6.

Various requirements implicitly encode which component should talk to which
other component. I'm not sure that the requirement document is the right
place for encoding architecture details of potential implementations of such
a measurement networks.

As I wrote in the previous mail I'm not entirely convinced that one must
connect the network parameter server to measurement clients. I do see a
potential benefit for a parameter server function in general, mainly to help
interpreting the results.

Some specifics:

A-1: the distinction between "network providers" and "one or more third
parties" is not clear. Who are third parties? Why are "network providers"
not third parties?

A-3 is in fact not a requirement.

A-4 cannot be a must. There are measurement networks out there that do
either active or passive but not both, due to policy or technicalities. It'd
be a serious limitation to require being able and willing to do both.

C-3, C-4, D-5 and D-6 are really requirements for clients, not data collectors.

C-3 seems to mandate a controller in each ISP's network. That's probably not
a good idea.

D-9 uses strange wording, especially in the light of requiring
authentication and such.

N-4 implicitly states that there *is* a connection between the client and
the parameter server. Maybe there isn't.

Regards,
Robert

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Tue, 25 Sep 2012 16:14:57 +0000

Hello,

   More general comments on a framework -

Parameter server -  
	The Broadband forum does have a standard for running these types of access performance tests that uses the TR-69 protocol to secure communications with the end device.  however it is mostly operational and being changed to become a large scale test.   

The current work there uses a test type, and test vector (string of test attributes) to ensure that the test is repeatable.   The current BBF document aims to create a "list of test" so that all the entities can have test inter-operability.   

Many of the tests today such as RFC 2544 have been implemented with different failure thresholds (a lab test vs. a in-service field test set).  In any case we'll have to be careful of the test attributes are explicitly identified per test, even down to the failure / exception thresholds levels otherwise two different test systems my not interoperate even with the same test.  

   My original assumption was that the tests would be standardized and be "capabilities" of each end point, vs. on a parameter server - however I'm being open minded to see what that framework might enable as well.   

Regards,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Kisteleki
Sent: Tuesday, September 25, 2012 10:38 AM
To: [email-masked]
Subject: [lmap] Some comments

Hi,

General comments:

Rather than saying "component X should authenticate/authorize component Y"
numerous times, and "component X should allow for optional encryption and integrity protection" it's most likely better to say something like "all components exchanging information should use mutually authenticated, encrypted and integrity protected channels". That'd simplify a lot of the requirements in section 6.

Various requirements implicitly encode which component should talk to which other component. I'm not sure that the requirement document is the right place for encoding architecture details of potential implementations of such a measurement networks.

As I wrote in the previous mail I'm not entirely convinced that one must connect the network parameter server to measurement clients. I do see a potential benefit for a parameter server function in general, mainly to help interpreting the results.

Some specifics:

A-1: the distinction between "network providers" and "one or more third parties" is not clear. Who are third parties? Why are "network providers"
not third parties?

A-4 cannot be a must. There are measurement networks out there that do either active or passive but not both, due to policy or technicalities. It'd be a serious limitation to require being able and willing to do both.

C-3 seems to mandate a controller in each ISP's network. That's probably not a good idea.

D-9 uses strange wording, especially in the light of requiring authentication and such.

N-4 implicitly states that there *is* a connection between the client and the parameter server. Maybe there isn't.

Regards,
Robert

_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap