Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-bier-isis-extensions-06

2018-02-13 Thread Meral Shirazipour 
Hi Les,
  Thank you for addressing the comments. All good by me.

Best,
Meral

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, February 12, 2018 9:01 PM
To: Meral Shirazipour ; 
draft-ietf-bier-isis-extensions@ietf.org; gen-art@ietf.org
Subject: RE: Gen-ART Telechat Call review of draft-ietf-bier-isis-extensions-06

Meral -

Thanx for the review.
Some of your comments have already been addressed in the latest version (07) 
published a few days ago.

Responses inline.

From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com]
Sent: Monday, February 12, 2018 8:02 PM
To: 
draft-ietf-bier-isis-extensions@ietf.org;
 gen-art@ietf.org
Subject: Gen-ART Telechat Call review of draft-ietf-bier-isis-extensions-06

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

For more information, please see the FAQ at 
.

Document: draft-ietf-bier-isis-extensions-06
Reviewer: Meral Shirazipour
Review Date: 2018-02-12
IETF LC End Date: 2018-02-22 ?
IESG Telechat date: 2018-02-22

Summary: This draft is ready to be published as Standards Track RFC but I have 
some comments.

Major issues:
Minor issues:
Nits/editorial comments:
-please updated references to latest draft version/RFC number

[Les:] Done in V 07

-Section 2 would be clearer is the definitions introduced only in this document 
are identified as such

[Les:]  I don't think there are any introduced by this document. All of the 
definitions mentioned in Section 2 come from RFC 8279.

-Please spell out  multi topology, sub-domain at  first use for MT SD
[Les:] In Section 4.1 where we introduce the use of  here is what the 
text says (emphasis added):

"Within such a domain, the extensions defined in this document
   advertise BIER information for one or more BIER sub-domains.  Each
   sub-domain is uniquely identified by a subdomain-id.  Each subdomain
   is associated with a single ISIS topology [RFC5120], which may be any
   of the topologies supported by ISIS.  Local configuration controls
   which  pairs are supported by a router."

Do you think further clarification as to the meaning of  is still 
needed??

-[Page 6], "advertisments."--->"advertisements"

[Les:] Corrected in V 07.

-[Page 8], "occurences"--->"occurrences"

[Les:] The section which contains this misspelling was removed in V 07.

   Les

Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Non-DoD Source] Genart last call review of draft-ietf-lwig-crypto-sensors-05

2018-02-13 Thread KELLY, MICHAEL B CTR USAF AFMC 412 TENG/ENI 
Hello All,

I was invited into this list because I had some questions.  I am not able to 
contribute anything so would someone be so kind as to remove me from this list. 
 My email is michael.kelly.49@us.af.mil

Thank you for your time,
M Bryan Kelly
JT3/ATAC Contractor
412 TENG/ENIE CANIS Software
661-277-7852
DSN 527-7852
Blg 1600 Block 500
300 E. Yeager Blvd
Edwards AFB, 93524

-Original Message-
From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Dan Romascanu
Sent: Tuesday, February 13, 2018 2:44 AM
To: gen-art@ietf.org
Cc: l...@ietf.org; droma...@gmail.com; i...@ietf.org; 
draft-ietf-lwig-crypto-sensors@ietf.org
Subject: [Non-DoD Source] Genart last call review of 
draft-ietf-lwig-crypto-sensors-05

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-lwig-crypto-sensors-05
Reviewer: Dan Romascanu
Review Date: 2018-02-13
IETF LC End Date: 2018-02-19
IESG Telechat date: 2018-02-22

Summary:

This is a well-written clear informational memo, documenting methods to secure 
networks built of resource-constrained devices. It describes a deployment model 
based on exchanges of signed objects, and documents available cryptographic 
libraries that may be suited to the targets. The conclusions include analysis 
of trade-offs and recommendations for future development and deployments.

The document is READY from Gen-ART perspective. There are a couple of 
non-blocking issues that I would be glad to have them clarified before 
approval. I have also pointed to a couple of nits.

Major issues:

Minor issues:

1. In Section 7:

'The location of the resource directory was configured into
   the smart object sensor by hardcoding the IP address'

Is this reasonable? I understand that the goal of the exercise was to 
demonstrate that it is possible to implement the entire architecture with 
public-key cryptography on an 8-bit micro-controller, but hard-coding the IP 
address seems to be below the threshold of a functional system. IMO there is a 
need to be able for the sensor to acquire this address (DHCP stack, or a simple 
UI to stream in one address, etc.)

2. In section 8.1 - I would expect some discussion about the extra-power needed 
to run the cryptography. There is a statement about these being less than 
device wake-up and sending messages, but some quantitative evaluation (in
percentage) of the impact would be useful, taking into account that battery 
capacity is one of the most important constrained resources.

Nits/editorial comments:

1. The document uses the alternate term of 'small devices' for 
'resource-constraint devices'. I view this as kind of an inaccurate verbal 
automatism in the world of IoT, as 'small' is a relative term, 
resource-constrained devices are not necessarily small (like in reduced 
physical footprint), and small devices can be rich in resources. I would 
suggest to either avoid the term, or explain what it means in the context (e.g.
''Smart objects', 'small devices' and 'resource-constrained devices are used 
interchangeably in this document and mean ...')

2. Please expand ECDSA at first occurrence



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-lwig-crypto-sensors-05

2018-02-13 Thread Dan Romascanu 
Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-lwig-crypto-sensors-05
Reviewer: Dan Romascanu
Review Date: 2018-02-13
IETF LC End Date: 2018-02-19
IESG Telechat date: 2018-02-22

Summary:

This is a well-written clear informational memo, documenting methods to secure
networks built of resource-constrained devices. It describes a deployment model
based on exchanges of signed objects, and documents available cryptographic
libraries that may be suited to the targets. The conclusions include analysis
of trade-offs and recommendations for future development and deployments.

The document is READY from Gen-ART perspective. There are a couple of
non-blocking issues that I would be glad to have them clarified before
approval. I have also pointed to a couple of nits.

Major issues:

Minor issues:

1. In Section 7:

'The location of the resource directory was configured into
   the smart object sensor by hardcoding the IP address'

Is this reasonable? I understand that the goal of the exercise was to
demonstrate that it is possible to implement the entire architecture with
public-key cryptography on an 8-bit micro-controller, but hard-coding the IP
address seems to be below the threshold of a functional system. IMO there is a
need to be able for the sensor to acquire this address (DHCP stack, or a simple
UI to stream in one address, etc.)

2. In section 8.1 - I would expect some discussion about the extra-power needed
to run the cryptography. There is a statement about these being less than
device wake-up and sending messages, but some quantitative evaluation (in
percentage) of the impact would be useful, taking into account that battery
capacity is one of the most important constrained resources.

Nits/editorial comments:

1. The document uses the alternate term of 'small devices' for
'resource-constraint devices'. I view this as kind of an inaccurate verbal
automatism in the world of IoT, as 'small' is a relative term,
resource-constrained devices are not necessarily small (like in reduced
physical footprint), and small devices can be rich in resources. I would
suggest to either avoid the term, or explain what it means in the context (e.g.
''Smart objects', 'small devices' and 'resource-constrained devices are used
interchangeably in this document and mean ...')

2. Please expand ECDSA at first occurrence


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art