Re: [Gen-art] Genart last call review of draft-ietf-intarea-frag-fragile-13

[Pete Resnick]

On 5 Jul 2019, at 10:00, Fred Baker wrote:

In Section 2.1 and 2.2, Instead of "set to one" and "set to zero", it 
would
read easier with "set to (1)" and "set to (0)", or some similar 
construction.


That seems to me to be stylistic - I'm not at all sure what makes 
"(1)" more readable than "one". I'm making the change, but I can't 
begin to fathom how it improves the document.


Yes, it is completely stylistic and I'm sorry I was not more explicit 
about that earlier: It was mostly that it was inconsistent (sometimes 
using the digit in parens, sometimes using the word), but in at least 
one instance I read "set to one" too quickly and parsed it as "set to 
one of" something or other. Just using the digit as you had in your 
second message is perfectly fine.


Section 3 is in an odd place. I'd say either move it up to the top, 
or put it

down in section 7.


Moved to section 1.


Yeah, that's fine. Again, just a stylistic thing.

4.2 mentions virtual reassembly. Virtual reassembly applies to 4.1, 
4.3, and
4.4 as well. Perhaps moving the discussion of virtual reassembly up 
to the top

of 4 would make more sense.


I think you're inferring the applications to 4.1, 4.3, and 4.4. 4.1, 
for example, makes rather a point that in the absence of virtual 
reassembly the router will make different routing decision. (I could 
say "incorrect", but the issue is that it is in fact making a correct 
decision in what could be argued to be the wrong context). I'll see 
what I can do with this, but I'm going to have to ask you to look at 
the diff and see whether you agree with the change.


Yeah, that's exactly what I was thinking of. I like the new 3.1, though 
I would change "It can be useful in" to "It could be useful to address 
the problems in". That is, it doesn't really address those problems, 
because you couldn't really use it in those contexts.


In 4.5, insert "duplicate IDs resulting in" after prevent. It took me 
a bit to

figure out what this was referring to. Also, change "are not easily
reproducible" to "do not occur as frequently"; I think it reads 
better.


Ack

And just to yell into the wind: Section 7.3 seemed a little wimpy to 
me, but I
can't for the life of me figure out how to make it any stronger or 
more likely

to be listened to. End of pointless yelling.


Ron started out with "let's just deprecate Internet Layer 
Fragmentation entirely." Good luck, great way to create an RFC that 
will be completely ignored. Ain't Gonna Happen In Practice. We backed 
off to this in a quest for comments that could actually have an 
impact. Agree that they don't have teeth.


Yep, what I figured.

Would you kindly review the attached diff and comment on the changes? 
I'll wait for your comments before uploading.


Yep, looks pretty good to me. Thanks.

pr
--
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best

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

[Gen-art] Genart telechat review of draft-ietf-tram-turnbis-27

[Vijay Gurbani via Datatracker]

Reviewer: Vijay Gurbani
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 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-tram-turnbis-27
Reviewer: Vijay K. Gurbani
Review Date: 2019-07-05
IETF LC End Date: None
IESG Telechat date: 2019-07-11

Summary: Ready to proceed.  I had reviewed -25 for Gen-ART and all of my
comments and feedback from that review have been incorporated.  I do not have
any further comments or feedback on -27.

Major issues: 0

Minor issues: 0

Nits/editorial comments: 0


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

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

[Nabil Benamar]

Dear Roni,

Thank you for your review. Indeed, you raised a crucial privacy issue that
we need to tackle in this draft.

If we look at https://tools.ietf.org/html/rfc8065 which recommends the
generic https://tools.ietf.org/html/rfc8064, we can say that we  comply by
inheritance from Ethernet since our current draft is targeted at using the
RFC 2464 (plus IPv6 suite over Ethernet) with minimal changes, as we
mention in the abstract (...for using IPv6 to communicate among nodes in
range of

   one another over a single IEEE 802.11-OCB link *with minimal change to *

*   existing stacks*).


However, there are some specificities related to vehicles. Since they roam
a lot, the use of a same Link Local Address over time can leak the presence
of the same vehicle in multiple places. Location tracking, if the same
interface identifier is used with different prefixes as a device/vehicle
moves between different networks.


Hence, a vehicle should get hints about a change of environment (e.g. ,
engine running, GPS, whatever) and renew the IID in LLAs.



I can make these proposed changes in a separate sub-section to emphasize
the concern and fix the privacy issue.


Thank you!

On Thu, Jul 4, 2019 at 7:05 AM Roni Even via Datatracker 
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:
>
>
>

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-v6ops-nat64-deployment-06

[Jordi Palet Martínez]

No problem, understood, and many thanks!

Regards,
Jordi
@jordipalet
 

El 5/7/19 5:21, "Warren Kumari"  escribió:

On Thu, Jul 4, 2019 at 6:52 AM Jordi Palet Martínez
 wrote:
>
> Hi Meral,
>
>
>
> I just realized, if I understood correctly, that from GENART the review 
is completed, however, this has not been reflected at the document page:
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/
>
>
>
> Warren, I saw that it has been placed in the agenda of the next telechat, 
but opsdir review is also missing.

Yes, yes it is -- reviewers are volunteers, and often the review
arrives just before the telechat, and sometimes they don't arrive at
all.
Directorate reviews are mainly for the benefit of the AD - don't sweat
it if the review doesn't show up, it's not a blocker for the
document...
W

>
>
>
> Thanks!
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
> El 27/6/19 19:43, "Jordi Palet Martínez"  
escribió:
>
>
>
> Thanks a lot Meral!
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
> El 27/6/19 18:43, "Meral Shirazipour"  
escribió:
>
>
>
> 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-v6ops-nat64-deployment-06
>
>
>
> Reviewer: Meral Shirazipour
>
> Review Date: 2019-06-27
>
> IETF LC End Date: 2019-06-28
>
> IESG Telechat date: NA
>
>
>
>
>
> Summary: This draft is ready to be published as Informational RFC .
>
>
>
>
>
> Major issues:
>
>
>
> Minor issues:
>
>
>
> Nits/editorial comments:
>
>
>
>
>
>
>
> Best Regards,
>
> Meral
>
> ---
>
> Meral Shirazipour
>
> Ericsson Research
>
> www.ericsson.com
>
>
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



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