reason given above.
Done
> Page 8, 5th paragraph, 1st sentence: change "requirements" to
> "requirement" for the same reason given above.
Done
> Page 10, 1st paragraph: append a comma after "traditional".
Done.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
, I've discussed this issue at a number of meetings,
and should say that the general reaction from the audience is that of
surprise. "Awareness" is another important ROI.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484
understanding is that
this document serves at these goals:
* Raising awareness among VPN users
* Suggesting workarounds to VPN users
* Raising awareness among vendors -- some of them have implemented
patches in response to this document.
* Briefly describing some tricky issues that might bite imp
On 02/19/2014 08:16 PM, Jari Arkko wrote:
> Thanks for your review, Russ. Is there a new version coming up?
Yes. I'll be posting it tomorrow as the latest.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0
nism SHOULD include a drop counter
dedicated to DHCPv6-Shield packet drops.
?
(and there are a few more requirements when it comes to *what* should be
logged, as noted by others during the IETF LC).
> -- section 7, first paragraph:
>
> Please expand DoS
ot;header chain" alone, but rather "IPv6 header chain".
>>> -- section 3, "Upper-Layer Header"
>>>
>>> Again, this section talks about the term without defining it.
>>>
>>> -- section 5, list entry "1": "... th
d other places): I have a concern about OS names,
> for instance I prefer Microsoft Windows to simply Windows.
> BTW the current offical name of Mac OS (MacOS) X is (Apple) OS X.
We'll double-check and update as needed.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg..
ell... this was based on previous experience
with other documents I had authored...
(Double-checking: No changes needed in this respect, right?)
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25
nce describing what the figure is about would be reather complex
in a single-liner... But I will give it a try.
> -General, please
> spell out acronyms at first use, e.g. PRNG, DoS etc.
Will do.
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP
quot;that needs to fragmented"--->"that needs to be fragmented"
Will fix this.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Gen-art mai
ttps://tools.ietf.org/html/draft-gont-predictable-protocol-ids>) and
they shouldn't even be considered an option.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
__
Reviewer: Fernando Gont
Review result: Ready with Nits
** Technical **
* Section 3, pages 3-4:
>Intended algorithm for mcpttq is queuing.
>
>New Warning code: No.
>
>New SIP response code: No.
Is this kind of thing really needed/required in the registry?
e comments just like any
other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Here's my review:
On 12/16/2016 06:46 PM, Fernando Gont wrote:
> Reviewer: Fernando Gont
> Review result: Ready with Nits
>
ion)?
Thanks!
Best regards,
Fernando
Forwarded Message
Subject: Re: [Gen-art] Review of
draft-holmberg-dispatch-mcptt-rp-namespace-03
Date: Fri, 16 Dec 2016 18:48:59 -0300
From: Fernando Gont
To: gen-art@ietf.org
CC: i...@ietf.org, draft-holmberg-dispatch-mcptt-rp-namespace
there are pending actions on
the reviewer's side?
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Gen-art mailing list
Gen-art@ietf.org
https
Reviewer: Fernando Gont
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
expansion of TCPM WG (TCP Maintenance
Working Group).
Fixed!
Please let me know if the above address your comments
Thanks so much!
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
o ICMP soft errors.
>
> I have not incorporated this change. But please let me know if you
> feel strongly about it.
I think the old wording seriously overstates the scope of the draft, but
this is an editorial problem, not a technical one. I would still prefer
to see this changed.
ts without having to add text back to the I-D.
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Gen-art mailing list
Gen-art@ietf.org
https://
will not have different sequences of port numbers; i.e., will not be
Fixed.
> Line 869
>availability an the granularity requested. With SCTP both hostnames
> ->availability and the granularity requested. With SCTP both hostnames
Fixed.
Thanks!
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
oses an alternative ISN-generation scheme
>> which results in monotonically-increasing timestamps across
>> ^^ ISNs
>> connections that are not easily-predictable by an off-path attacker."
>>
>> - 8.2 page 9 [INFOCOM-99] and [Silbersack]]: ' .' -> '.'
>>
>> Thanks
>>
>> francis.dup...@fdupont.fr
>> ___
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>
>
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
neration scheme
>which results in monotonically-increasing timestamps across
> ^^ ISNs
You're right. Thanks for catching this one! -- Will fix it.
> connections that are not easily-predictable by an off-path attacker.&qu
cument.
> 9) S4.1.1.4, page 52, first bullet item, first sentence ---
> what do you mean by "overlapping fragments"? Maybe you meant,
> instead, "duplicate fragments"?
No, I did mean "overlapping fragments" -- i.e., fragments that contain a
porti
(8191*8) bytes/
Sounds reasonable. Will do.
> Thanks for entertaining my rather late review.
Thanks *you* for your feedback!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
the top of the next page.
I'm sure the RFC-Editor will take care of this.
P.S.: (All my "done", "fixed", etc., are subject to the documents
shepard's agreement ;-) )
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fin
n (in a similar way to [I-D.ietf-opsec-ip-options-filtering] for
> the IPv4 case)."
I've removed such sentence altogether, upon suggestion by Wes Eddy.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
ion--> put "(CPA)" right after
> "Certification Path Advertisement messages"
I will apply the suggested edits to the next rev.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E
ces: RFC1948 is obsoleted by 6528. Is there a reason to
> reference the obsolete version?
Yes: RFC1948 is only referenced in the Acks section, where I note that
this document was inspired by Bellovin's work on RFC1948. While RFC6528
obsoletes RFC1948, the algorithm in that RFC is the sam
Acks section, where I note
>> that this document was inspired by Bellovin's work on RFC1948.
>> While RFC6528 obsoletes RFC1948, the algorithm in that RFC is the
>> same as that in RFC1948.
>
> So 6528 equally illu
appropriate. If you mean the MUSTs, then
> these are _requirements_.
Agreed. For instance, Karl Auer reported this one a couple of days ago.
I'll be s/desired/required/ in the upcoming -08 version.
Thanks so much!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6net
ith respect to
packet loss. And if you retransmit RAs more frequently, you e.g. harm
battery life of mobile devices.
So this are values that result in prefixes being deprecated in a
timelier manner, while being within the current specs and BCPs
(RFC4861/RFC7772). If needed, we
Hello, Dale,
On 3/9/20 22:11, Dale R. Worley wrote:
Fernando Gont writes:
Thanks so much for your feedback! Please find my responses in-line
You're welcome!
To be clear, I'm not disagreeing with you about any of this as questions
of *fact*, but rather saying that these
at it
generally implies that the device records prefixes on non-volatile
storage. But there are valid reasons for which a device might be unable
to (e.g., economical, if you wish).
Then, the "MUSTs" elsewhere essentially try to signal how crucial
implementation of each specific behav
ations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
== The 'Obsoletes: ' line in the draft header should list only the
_numbers_ of the RFCs which will be obsoleted by this document (if
app
ng the cookie supplied
by the browser to identify what earlier queries had been made (e.g.,
for what type of information). Based on the earlier queries,
advertisements can be targeted to match the (assumed) interests of
the end-user.
cut here
?
Would this address your con
we can move (or copy) that section
into this document.
Thanks, and Happy New Year!
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Gen-art mailing list
Gen-art
36 matches
Mail list logo