Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ecrit-ecall-21

[Meral Shirazipour]

Hi,
  Thank you. 

Best,
Meral

> -Original Message-
> From: Randall Gellens [mailto:rg+i...@randy.pensive.org]
> Sent: Friday, January 06, 2017 4:07 AM
> To: Meral Shirazipour ; draft-ietf-ecrit-
> ecall@tools.ietf.org; gen-art@ietf.org
> Subject: Re: Gen-ART Last Call review of draft-ietf-ecrit-ecall-21
> 
> Hi Meral,
> 
> Thank you for your review, I appreciate it.  Please see inline.
> 
> At 12:11 AM + 1/6/17, Meral Shirazipour wrote:
> 
> >  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-ecrit-ecall-21
> >  Reviewer: Meral Shirazipour
> >  Review Date: 2017-01-05
> >  IETF LC End Date: 2017-01-06
> >  IESG Telechat date: 2017-01-19
> >
> >
> >  Summary: This draft is ready to be published as Standards Track RFC
> > but I have comments.
> >
> >  Major issues:
> >
> >  Minor issues:
> >  -I find the document could be clearer if put in context with other
> > documents related to the topic/if any.
> >  -By eCall do we mean voice and video calls? (is emergency sms another
> > possibility?)
> 
> The Introduction has text explaining that an eCall establishes a voice 
> channel and
> carries vehicle data, but I added "providing a voice channel and transmission 
> of
> data" earlier in the section to make this more clear.  eCall does not use SMS.
> 
> >
> >  Nits/editorial comments:
> >  -General: "next-generation eCall" and "NG-eCall" are both used.
> > Would be clearer to use only one.
> >  -[Page 10], "PSAP interpets"--typo-->"PSAP interprets"
> >  -[Page 13], "package to accomodate"--typo-->"package to accommodate"
> >  -[Page 17], "how it it used"->"how it is used"
> >  -[Page 17], "when it is is required"->"when it is required"
> >  -[Page 18], "it is is required"->"it is required"  (two
> > occurrences)  -[Page 18], "how it it used."->"how it is used."
> > (two occurrences)  -[Page 37], "Based on the the">"Based on the"
> >
> 
> Thank you.
> 
> --
> Randall Gellens
> Opinions are personal;facts are suspect;I speak for myself only
> -- Randomly selected tag: --- The only normal people 
> are the
> ones you don't know very well.
> --Joe Ancis

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

Re: [Gen-art] Review of draft-ietf-nvo3-use-case-15

[Lucy yong]

Hi Ralph,

Thank you for the review. We will have all acronyms expansion in next version 
and add a reference for DC services.  

Regards,
Lucy

-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Ralph Droms
Sent: Friday, January 06, 2017 7:14 AM
To: gen-art@ietf.org
Cc: n...@ietf.org; draft-ietf-nvo3-use-case@ietf.org; i...@ietf.org
Subject: [Gen-art] Review of draft-ietf-nvo3-use-case-15

Reviewer: Ralph Droms
Review result: Ready with Nits

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-nvo3-use-case-??
Reviewer: Ralph Droms
Review Date: 2017-01-06
IETF LC End Date: 2017-01-11
IESG Telechat date: 2017-01-19

Summary: This draft is ready for publication as an Informational RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: 

I found several acronyms that did not have expansions.  I recommend a pass over 
the document for unexpanded acronyms..

Section 2: What is "broadcast/unknown" traffic (spec. "unknown"?); please 
expand the acronym "BUM".
  The paragraph that begins with "One NVO3 network [...]" is indented 
differently from the rest of the text.  Intentional or a typo?

Section 3.2: An illustrating figure for the use case described in this section 
would be helpful.
  Expand acronyms "PE" and "ABSR".
  I found the text using "Option A" and "Option B" confusing.  Exactly what are 
those options?

Section 5: I didn't understand the references to IaaS, PaaS and SaaS in the 
summary - there are no references to those services in the body of the 
document, or back pointers from the summary to relevant preceding text.

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

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

Re: [Gen-art] [6tisch] Review of draft-ietf-6tisch-minimal-17

[PWK]

Kris; I totally agree with your explanation, but perhaps a slight editorial 
change?

"This specification assumes the existence of one protocol identifier, P1, and 
one cryptographic
key K2.  P1’s purpose is to provide message integrity, it is not to provide 
security.”

Pat


On 5, Jan2017, at 15:44, Kristofer PISTER  wrote:

Tero - you bring up a good point that after all of the discussion of this issue 
we have
still not done a good job explaining it, since it's clear that there are still 
misunderstandings.

The text in section 4.6 says "This specification assumes the existence of two 
cryptographic keys."
That is incorrect, and should be changed.  I propose
"This specification assumes the existence of one protocol identifier, P1, and 
one cryptographic
key K2.  P1 provides no security."

Let me go over the reasoning behind having P1.  Any implementation of 6TiSCH 
has one of
three choices for message integrity on the EBs:
1) use no message integrity
2) use a well-known protocol identifiier, with no security value
3) use a secret key

There is ample evidence that sending 15.4 frames without message integrity is 
problematic, so 
we'd prefer not to do option 1.
Option 2 provides no security, but it does provide message integrity, and it 
provides some level
of confidence that the sender of the frame is using the same version of the 
protocol that the
receiver is using.
Option 3 provides all of the benefits of option 2, plus some level of security. 
 It is a fine option,
but it assumes the existence of a pre-distributed cryptographic key K1, which 
is a non-starter.

ksjp

On Thu, Jan 5, 2017 at 8:04 AM, Tero Kivinen > wrote:
Brian E Carpenter writes:
> Hi Thomas,
>
> The responses to my comments almost all look fine to me. Just one point,
> on MINOR COMMENT 4 (slide 8):
>
> "Shouldn't this also say that this value MUST NOT be used in
> operational networks?"
>
> We've seen many cases over the years of informal values making it into shipped
> products... generally a Bad Thing. But with my lack of IEEE802.15.4 expertise,
> I really don't know whether it matters in this case. Whatever the WG decides
> is good, as long as the point is considered.

It does matter. If anybody knows the key they can do single packet DoS
attack against network and kill it...

I.e. send EB to some of the nodes, so that it changes the schedule.
After that the nodes in the network are out of sync, and after few
minutes or tens of minutes they will realize this and start to
recover, but it takes long time, and can cause lots of disruption.

If node receives EB which says that the EB slot is not timeslot 0, or
that it has channel offset of 1 or something like that, then it will
be listening EBs from wrong channel after that. After it misses enough
of packets from the network it realizes it is out of sync and
reinitializes itself back to network. This means it needs to do
passive scan over the 16 channels listening each channel for slot
frame size * timeslot duration * EB_PERIOD (at minimum, perhaps twice
in case it happens to miss EB). Meaning that with 101 slot frames, and
10ms timeslot duration, and with EB_PERIOD of 3 that is 3 seconds per
channel, and for 16 channels it takes 48 seconds.

During that time nodes which were children of that node, will notice
that it has gone, and they will start doing same...

The attacker can cause even more confusion by changing the timeslot
parameters, or channel hopping order, but I would hope that
implementations would ignore changes to those IEs while the network is
running.

On the other changing channel offset or timeslot number for EBs, is
something that might happen, so nodes might need to cope with that.

I have complained this clear text password in the specification for
long time, and I do not think there is any reason to include that key
in the RFC. The early interoperability testing people can agree on key
they use in the interoperability events it does not need to be
hardcoded in the RFC or in the code.

> I hope the interim goes well, it is too far out of my time zone to attend!
--
kivi...@iki.fi 

___
6tisch mailing list
6ti...@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Gen-art] Review of draft-ietf-nvo3-use-case-15

[Ralph Droms]

Reviewer: Ralph Droms
Review result: Ready with Nits

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-nvo3-use-case-??
Reviewer: Ralph Droms
Review Date: 2017-01-06
IETF LC End Date: 2017-01-11
IESG Telechat date: 2017-01-19

Summary: This draft is ready for publication as an Informational RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: 

I found several acronyms that did not have expansions.  I recommend a
pass over the document for unexpanded acronyms..

Section 2: What is "broadcast/unknown" traffic (spec. "unknown"?);
please expand the acronym "BUM".
  The paragraph that begins with "One NVO3 network [...]" is indented
differently from the rest of the text.  Intentional or a typo?

Section 3.2: An illustrating figure for the use case described in this
section would be helpful.
  Expand acronyms "PE" and "ABSR".
  I found the text using "Option A" and "Option B" confusing.  Exactly
what are those options?

Section 5: I didn't understand the references to IaaS, PaaS and SaaS
in the summary - there are no references to those services in the body
of the document, or back pointers from the summary to relevant
preceding text.

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

Re: [Gen-art] Review of draft-ietf-ecrit-car-crash-20

[Randall Gellens]

At 9:53 PM +0200 1/5/17, Dan Romascanu wrote:


 Hi,

 Thanks for the quick answer and for addressing my comments.

 On respect to:

 There is no conflict, as the eCall document applies to regions 
that adhere to the E.U. eCall system, and this document applies to 
other regions.  I added the following sentence to the paragraphs 
in the Abstract and Introduction:


A vehicle designed for multiple regions will
comply with the document applicable to the region in which it is
located.

 I do not believe that this is sufficiently clear. Do you mean here 
that this document applies to all regions that do not implement the 
eCall system? If so, please say it explicitely.


 Also, what does 'comply' mean? Is this about what is implemented in 
the software, or about what is activated? Without this 
clarification, your usage of MANDATORY and OPTIONAL keywords is 
fuzzy.


Hi Dan,

On reflection, I've deleted the two added sentences:

A vehicle designed for multiple regions will
   comply with the document applicable to the region in which it is
   located.

The Introduction already says:

   Vehicles
   designed to operate in multiple regions might need to support eCall
   as well as NG-ACN as described here.  A vehicle IVS might determine
   whether to use eCall or ACN by first determining the region or
   country in which it is located (e.g., from a GNSS location estimate
   and/or identity of or information from an MNO).  If other regions
   adopt other data formats, a multi-region vehicle might need to
   support those as well.

I think this text is better than the added sentences, and I agree 
with you that the added text introduced its own ambiguity.


--Randy

 On Thu, Jan 5, 2017 at 9:11 PM, Randall Gellens 
<rg+i...@randy.pensive.org> wrote:


 Hi Dan,

 Thanks for your review.  Please see in-line.


 At 3:13 AM -0800 1/5/17, Dan Romascanu wrote:

  Reviewer: Dan Romascanu
  Review result: Almost Ready

  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


<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

  Document: draft-ietf-ecrit-car-crash-20
  Reviewer: Dan Romascanu
  Review Date: 2017-01-05
  IETF LC End Date: 2017-01-06
  IESG Telechat date: 2017-01-19

  Summary:

  It's a good and useful document which needs to be read and understood
  together with the eCall document, and other relevant documents from
  EC, NENA, APCOT. There is at least one major issue that deserves
  discussion and clarification before approval, IMO.

  Major issues:

  1. One aspect of the relationship with eCall is unclear to me.

  The Abstract says:

   This document is an extension

 of the eCall document, with the primary differences being that
  this
 document makes the MSD data set optional and VEDS mandatory, and
  adds
 attribute values to the metadata/control object to permit greater
 functionality.

  Then in the Introduction:

  This document reuses the technical aspects of next-generation pan-

 European eCall (a mandated and standardized system for emergency
 calls by in-vehicle systems within Europe), as described in
 [I-D.ietf-ecrit-ecall].  However, this document specifies a
  different
 set of vehicle (crash) data, specifically, the Vehicle Emergency
  Data
 Set (VEDS) rather than the eCall Minimum Set of Data (MSD).

  and in Section 9:

   This document extends [I-D.ietf-ecrit-ecall] by reusing the call

  set-
 up and other normative requirements with the exception that in
  this
 document, support for the eCall MSD is OPTIONAL and support for
  VEDS
 in REQUIRED.

  First of all it's not clear if by 'eCall document' what it's meant is
  the European document or draft-ietf-ecrit-ecall.


 My understanding is that references are frowned upon in Abstracts, 
otherwise there would be a reference to the IETF eCall draft there. 
I did change "extension of the eCall document" to "extension of the 
IETF eCall document" to try and make this more clear.


   Second it's not clear
  how the two IETF documents, both on standards track relate, when the
  status of the MSD and VEDS data sets are different. What would
  prevail? The IESG is asked to approve two document, both on standards
  track, with different and in this case contradictory content. If I am
  a car manufacturer, I would ask myself what support will be mandatory
  to implement? Or maybe there are different scenarios where the
  different data sets are recommended? But then should not support for
  both be mandatory to implement and optional to use, maybe per
  geographical area? After all vehicles cross borders, or are
  transported / exported over the seas nowadays.


 There 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ecrit-ecall-21

[Randall Gellens]

Hi Meral,

Thank you for your review, I appreciate it.  Please see inline.

At 12:11 AM + 1/6/17, Meral Shirazipour wrote:

 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-ecrit-ecall-21
 Reviewer: Meral Shirazipour
 Review Date: 2017-01-05
 IETF LC End Date: 2017-01-06
 IESG Telechat date: 2017-01-19


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


 Major issues:

 Minor issues:
 -I find the document could be clearer if put in context with other 
documents related to the topic/if any.
 -By eCall do we mean voice and video calls? (is emergency sms 
another possibility?)


The Introduction has text explaining that an eCall establishes a 
voice channel and carries vehicle data, but I added "providing a 
voice channel and transmission of data" earlier in the section to 
make this more clear.  eCall does not use SMS.




 Nits/editorial comments:
 -General: "next-generation eCall" and "NG-eCall" are both used. 
Would be clearer to use only one.

 -[Page 10], "PSAP interpets"--typo-->"PSAP interprets"
 -[Page 13], "package to accomodate"--typo-->"package to accommodate"
 -[Page 17], "how it it used"->"how it is used"
 -[Page 17], "when it is is required"->"when it is required"
 -[Page 18], "it is is required"->"it is required"  (two occurrences)
 -[Page 18], "how it it used."->"how it is used." (two occurrences)
 -[Page 37], "Based on the the">"Based on the"



Thank you.

--
Randall Gellens
Opinions are personal;facts are suspect;I speak for myself only
-- Randomly selected tag: ---
The only normal people are the ones you don't know very well.
   --Joe Ancis

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