Re: [Gen-art] [ipwave] Genart telechat review of draft-ietf-ipwave-ipv6-over-80211ocb-47

[Roni Even (A)]

Hi,
I still do not think that the following sentence in section 5.2 text "The 
policy dictating when the MAC address is changed on the 802.11-OCB interface is 
to-be-determined." make sense. I think that a sentence that will say
“implementations should use a policy dictating when the MAC address is changed 
on the 802.11-OCB interface”

Roni


From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Alissa Cooper
Sent: Wednesday, July 10, 2019 11:47 PM
To: Suresh Krishnan
Cc: i...@ietf.org Discussion; i...@ietf.org; Gen art; 
draft-ietf-ipwave-ipv6-over-80211ocb@ietf.org; Nabil Benamar
Subject: Re: [Gen-art] [ipwave] Genart telechat review of 
draft-ietf-ipwave-ipv6-over-80211ocb-47

I reviewed the -49 version so my questions are on that version.
Alissa


On Jul 10, 2019, at 4:44 PM, Suresh Krishnan 
mailto:sur...@kaloom.com>> wrote:

Hi Nabil,
  Roni's telechat review is for the version on which I issued the ballot (in 
this case it is -47). If you think the issue is resolved in a later version (I 
do not believe so in this case), you can respond to point out the actual text 
change that you made to address Roni’s comment.

Thanks
Suresh


On Jul 10, 2019, at 4:38 PM, Nabil Benamar 
mailto:benama...@gmail.com>> wrote:

Hi Alissa,

Thank you for your review. However, I have updated the draft and now it's in 
-49 reflecting previous comments.


Best regards
Nabil Benamar
---
نبيل بنعمرو






On Wed, Jul 10, 2019 at 7:29 PM Alissa Cooper 
mailto:ali...@cooperw.in>> wrote:
Roni, thanks for your review. Alex, Nabil, thanks for your responses. I entered 
a DISCUSS ballot to try to get more clarity about the relationship between MAC 
address changes and IID changes, among other things.

Alissa

> On Jul 4, 2019, at 2:05 AM, Roni Even via Datatracker 
> mailto:nore...@ietf.org>> wrote:
>
> Reviewer: Roni Even
> 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 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-ipwave-ipv6-over-80211ocb-47
> Reviewer: Roni Even
> Review Date: 2019-07-03
> IETF LC End Date: None
> IESG Telechat date: 2019-07-11
>
> Summary:
> The document is ready to be published as a standard track RFC with an issue
>
> Major issues:
>
> Minor issues:
>
> this is about my previous comment.
> The text in section 5.1 "A vehicle embarking  an IP-OBU whose egress interface
> is 802.11-OCB may expose itself to  eavesdropping and subsequent correlation 
> of
> data; this may reveal data considered private by the vehicle owner; there is a
> risk of being tracked.  In outdoors public environments, where vehicles
> typically circulate, the privacy risks are more important than in indoors
> settings." and "there is a strong necessity to use protection tools such  as
> dynamically changing MAC addresses"
> so even though there are privacy concerns there is no normative text saying
> that some method is needed. "strong necessity" is not normative ..
>
> A new sentence was added to section 5.1 "An example of change policy is to
> change the MAC address of the OCB interface each time the system boots up"
>
> I got more confused by section 5.2 text "The policy dictating when the MAC
> address is changed on the 802.11-OCB interface is to-be-determined."
>
> So what I got from section 5.1 and 5.2 is that protection tools to address
> privacy concern are needed but without any normative text.  Dynamic changing
> of MAC address is an option, no other option is mentioned.  Example for when 
> to
> change MAC address is on system boot and the policy when to change MAC address
> is to be determined.
>
> To summarize what the document currently says is that privacy risks are more
> important for outdoor public environment and it is left for implementations to
> decide if and how to address it.
>
> Nits/editorial comments:
>
>
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
its mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/its


___
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-lamps-cms-hash-sig-08

[Dale Worley via Datatracker]

Reviewer: Dale Worley
Review result: 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

.

Document:  draft-ietf-lamps-cms-hash-sig-08
Reviewer:  Dale R. Worley
Review Date:  2019-07-17
IETF LC End Date:  2019-08-01
IESG Telechat date:  not known

Summary:

   This draft is in great shape and ready for publication as a
   proposed standard RFC, with only a few editorial nits.

Nits/editorial comments: 

2.2.  Leighton-Micali Signature (LMS)

   The [HASHSIG] specification supports five tree sizes:

  LMS_SHA256_M32_H5;
  LMS_SHA256_M32_H10;
  LMS_SHA256_M32_H15;
  LMS_SHA256_M32_H20; and
  LMS_SHA256_M32_H25.

This text seems redundant with the description in the preceding
paragraph.

   The LMS public key is the string consists of four elements: the

Perhaps "An LMS public key consists of ...".

  u32str(lms_algorithm_type) || u32str(otstype) || I || T[1]

The notation "T[1]" seems to be undefined (although the intended value
is described clearly in the preceding paragraph).

2.3.  Leighton-Micali One-time Signature Algorithm (LM-OTS)

  n -  The number of bytes associated with the hash function.
   [HASHSIG] supports only SHA-256 [SHS], with n=32.

"associated" seems to me to be vague.  Perhaps "The length in bytes of
the output of the hash function."

  ls - The number of left-shift bits used in the checksum function,
   which is defined in Section 4.4 of [HASHSIG].

"The number of left-shift bits" is not quite right.  Perhaps "The
number of bits of left-shifting used in ..." or "The amount/size of
the left-shift used in ...".

5.  Signed-data Conventions

This paragraph has to be a number of minor wording issues, which I
have described interline:

   As specified in [CMS], the digital signature is produced from the
   message digest and the signer's private key.  The signature is
   computed over different value depending on whether signed attributes

s/value/values/

   are absent or present.  When signed attributes are absent, the
   HSS/LMS signature is computed over the content.  When signed

It might help the reader to put a paragraph break before "When signed
attributes are present..."

   attributes are present, a hash is computed over the content using the
   same hash function that is used in the HSS/LMS tree, and then a
   message-digest attribute is constructed with the resulting hash

I would replace "with" with "containing" or "whose value is"

   value, and then DER encode the set of signed attributes, which MUST

For parallelism, this clause should start with a subject and a passive
verb.  Perhaps "the DER encoding is constructed of ...".

   include a content-type attribute and a message-digest attribute, and

It might be clearer if the clause "which MUST ... attribute" was put
in parentheses.

   then the HSS/LMS signature is computed over the output of the DER-
   encode operation.  In summary:

You can probably change "the output of the DER-encode operation" with
"the DER encoding".

The paragraph contains four clauses joined by three successive "and
then".  You probably want to change that, perhaps breaking it out as a
numbered/bulleted list.  (What does the Editor recommend?)

And in this computation:

  IF (signed attributes are absent)
  THEN HSS_LMS_Sign(content)
  ELSE message-digest attribute = Hash(content);

I think you want to add a hyphen:
s/message-digest attribute/message-digest-attribute/

   HSS_LMS_Sign(DER(SignedAttributes))

[END]


___
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-ospf-yang-23

[Erik Kline via Datatracker]

Reviewer: Erik Kline
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-ospf-yang-??
Reviewer: Erik Kline
Review Date: 2019-07-17
IETF LC End Date: 2019-07-17
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues:

Minor issues:

I feel like the "version" text in 2.3 was confusing.  The first thing I did was
glance back up the overview where I (a) didn't see "version" mentioned and (b)
initially thought that "af" was maybe a proxy for "version".

But then later on it seems that "version" is only a mandatory property of the
LSA.

I'm not sure that I have concretely useful suggestions for improving this text,
and in fact it might well be that for expected readers of the document this is
in fact a non-issue.  Just thought I'd relay my experience.

Nits/editorial comments:

Page 25: NMDA RFC is 8342, not 8242.

Page 81: references draft-ietf-bdf-yang-xx.txt. This is referenced
elsewhere in the doc (correctly), so I think just remove the -xx may
be fine?

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