[Gen-art] Gen-ART review of draft-ietf-kitten-aes-cts-hmac-sha2-10
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-kitten-aes-cts-hmac-sha2-10
Reviewer: Vijay K. Gurbani
Review Date: Jul-29-2016
IETF LC End Date: Jul-20-2016
IESG Telechat date: Unknown
This document is ready as an Informational.
Major: 0
Minor: 2
Nits: 1
Minor:
- S3, top of page 4, while defining "context": What is the format of this
optional string: is it comma separated? Or does it not matter because the
byte-string in context is supposed to be an opaque label? I ask because the
byte-string can contain multiple values (identities of parties, nonce,
etc.);
consequently, how does a receiver know where one value ended and another one
began.
I realize that when "context" is used for key derivation in the KDF,
individual
elements of the "context" does not matter; but since the text makes the
point
that "context" may include "identities of parties who are deriving
and/or using
the derived key material...", it seems appropriate that the recipient
know what
separates the ID from the nonce.
- S3, middle of page 4: "When the encryption type is
aes128-cts-hmac-sha256-128,
k must be no greater than 256." 256 what? Bits (I believe). Similarly for
384. Better to be complete.
Nits:
- S1, second paragraph: "...but do not use the simplified profile." Any
insight
into why simplified profile is not used may be helpful to the reader for the
sake of completeness. (Of course, if the reasons that the simplified
profile is
not being used are blatantly obvious to practicioners in this field,
then don't
worry about this comment. But if not, it may help.)
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-pal-eidr-urn-2016-01
On 07/05/2016 07:45 PM, Pierre-Anthony Lemieux wrote: Hi Vijay, A revised I-D that adds a note under "Rules for Lexical Equivalence" is available at [1]. [1] https://www.ietf.org/id/draft-pal-eidr-urn-2016-02.txt Awesome! Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-pal-eidr-urn-2016-01
Pierre: Thank you for attending to my comment. More inline. On 07/02/2016 03:30 PM, Pierre-Anthony Lemieux wrote: Hi Vijay, I appreciate the review and comment. That is, are the schemes (urn, eidr) part of the case-insensitive string match? Yes, it looks like "Lexical equivalence of EIDR-URN is defined by case-insensitive string match." should say "Lexical equivalence of URN-EIDR is defined by case-insensitive string match." This would confirm that the entire URN-EIDR string defined in "Declaration of syntactic structure" is considered for matching, including "urn:eidr:". I will appreciate if the "including 'urn:eidr:'" part made it into the draft. Implementers have varying level understanding as they attempt to divine RFC text. So to the extent that we can make our intent explicit with a few additional strokes of the pen (or the keyboard), we are all the more better off for it. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-pal-eidr-urn-2016-01
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-pal-eidr-urn-2016-01
Reviewer: Vijay K. Gurbani
Review Date: Jun-09-2016
IETF LC End Date: Jul-01-2016
IESG Telechat date: Jun-30-2016
This document is ready as an Informational.
Major: 0
Minor: 1
Nits: 0
Minor:
- S2, Rules for Lexical Equivalence. I think some more guidance should
be provided here. Specifically, are the following two EIDRs the same?
urn:eidr:10.5240:7791-8534-2C23-9030-8610-5
10.5240:7791-8534-2C23-9030-8610-5
That is, are the schemes (urn, eidr) part of the case-insensitive
string match?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-campbell-art-rfc5727-update-03
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-campbell-art-rfc5727-update-03
Reviewer: Vijay K. Gurbani
Review Date: Apr-29-2016
IETF LC End Date: Not known
IESG Telechat date: May-05-2016
This document is ready as a BCP; it has addressed the only comment I
had in -02 [1] review on Feb 26, 2016. I have no further comments on
this revision.
Major: 0
Minor: 0
Nits: 0
[1] http://www.ietf.org/mail-archive/web/gen-art/current/msg12972.html
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-netconf-yang-library-05
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-netconf-yang-library-05
Reviewer: Vijay K. Gurbani
Review Date: Apr-29-2016
IETF LC End Date: Not known
IESG Telechat date: May-05-2016
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ccamp-otn-signal-type-subregistry-03
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ccamp-otn-signal-type-subregistry-03
Reviewer: Vijay K. Gurbani
Review Date: Mar-11-2016
IETF LC End Date: Mar-14-2016
IESG Telechat date: Mar-17-2016
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 1
Nits:
- S2, s/This document introduces no new security/This document does not
introduce any new security/
(better grammatically)
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-campbell-art-rfc5727-update-02
Ben Campbell wrote:
We did not mean to imply that ART was limited to human communication.
That was intended to describe a subset of ART (the historically RAI
work; primarily the clusters of SIP, SDP,and RTP related groups plus
a few higher-in-the-stack groups such as RTCWEB).
Ben, thanks again. Yes, rtcweb I can see being primarily for human-
communications.
Would it help to characterize these as "historically among humans"?
Yes, that would perfectly solve this minor conundrum.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-campbell-art-rfc5727-update-02
Ben Campbell wrote:
(+ART ADs)
On 26 Feb 2016, at 14:43, Vijay K. Gurbani wrote:
Minor: - S1, "Other RAI working groups develop extensions to SIP
that do not change the core protocol, new applications of SIP, and
other technologies for interactive communication among humans."
Are we intentionally limiting interactive communications only to
"humans"? I would suspect that this would be limiting, no? A
bunch of SIP SUBS/NOTs happen between automaton, or machines.
Surely we don't want to exclude these in the future. My
suggestion would be to simply take out the phrase "among humans"
Hi Vijay,
Ben: Thank you for considering my comments. Inline, please.
Actually, the "human" part was intentional. RFC5727 was primarily
about technologies for human communication. Certainly some of those
technologies may be dual use (e.g. XMPP, SIP-Events), but the reason
they were historically in the RAI area is that the primary use cases
under consideration involved humans, or supported those that did.
I suspect that your view as an AD may be more nuanced than mine, but I
must admit that I am not entirely comfortable with limiting ART to
"human communications", as would be implied by the text as currently
written.
Certainly nothing in rfc3261 explicitly limits communications to humans.
Those boundaries are more blurred now since the merger of APP and RAI
into ART. But 5727 was primarily about the SIP change process. That
text in section 1 is intended to describe the scope of 5727, and in
section 3 to describe the subset of ART wgs that historically would
have been considered RAI.
(I do note the use of RAI that probably needs to be fixed, or at
least put into past tense.)
I believe that dropping the phrase "among humans" from the paragraph
does not impact any aspect that at least I can observe, and may indeed
have the benefit that no one in the future will claim that SIP cannot
be used for m2m communications because of the limiting phrase.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-campbell-art-rfc5727-update-02
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-campbell-art-rfc5727-update-02
Reviewer: Vijay K. Gurbani
Review Date: Feb-26-2016
IETF LC End Date: Not known
IESG Telechat date: Not known
This document is ready as a BCP, however, it does have 1 Minor issue
that I detail below.
Major: 0
Minor: 1
Nits: 0
Minor:
- S1, "Other RAI working groups develop extensions to SIP that do not
change the core protocol, new applications of SIP, and other
technologies for interactive communication among humans."
Are we intentionally limiting interactive communications only to
"humans"? I would suspect that this would be limiting, no? A
bunch of SIP SUBS/NOTs happen between automaton, or machines.
Surely we don't want to exclude these in the future. My suggestion
would be to simply take out the phrase "among humans".
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-dprive-edns0-padding-02
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-dprive-edns0-padding-02
Reviewer: Vijay K. Gurbani
Review Date: Feb-26-2016
IETF LC End Date: Not known
IESG Telechat date: Mar-03-2016
This document is ready as a Proposed Standard.
1 nit below.
Major: 0
Minor: 0
Nits: 1
Nits:
- S6, second paragraph:
s/provides only a benefit/only provides a benefit/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10
Rachel: Thank you for attending to all my comments.
I did not see the resolution to this one, though:
- S1.1: The taxonomy of a peer into a leecher or a seeder appears to be
absolute. In real swarms (BitTorrent), a peer trades chunks with
other peers, so it is a leecher but also a provider for certain
chunks. This eventuality is not considered here.
Any thoughts on how to proceed?
Other than that, I am fine with the resolution to the remaining ones.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-grow-bmp-15
John: With respect to your responses in [1] to my Gen-ART review, I am
fine with your proposed resolutions.
[1] http://www.ietf.org/mail-archive/web/gen-art/current/msg12397.html
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ppsp-base-tracker-protocol-10
Reviewer: Vijay K. Gurbani
Review Date: Oct-15-2015
IETF LC End Date: Not known
IESG Telechat date: Oct-15-2015
This document is ready as a Proposed Standard, however, it does have
some minor comments and nits that I detail below.
Major: 0
Minor: 3
Nits: 9
Minor:
- Generally speaking, I think one more round of edits for grammar and
clarity may not be a bad thing.
- S2, "The PPSP Tracker Protocol architecture is intended to be
compatible with the web infrastructure." What is the "web
infrastructure"? How is it defined? What does it mean to be
compatible with it? Perhaps you meant that the PPSP TP is a request-
response protocol, which characterizes many "web protocols"?
- S3.2.5, Table 4: "available_bandwidth | Upstream Bandwidth
available" is this provisioned upload bandwidth or instantaneous
upload bandwidth?
Nits:
- General comment: too much use of gratuitous capitalization (Request
message, Tracker, Peer etc.)
- S1.1, CHUNK is better defined as "An uniformly sized atomic subset of
the resource that constitutes the basic unit of data organized in P2P
..."
- S1.1, For uniformity when defining terms, you may want to think of
starting the definition of live streaming as "LIVE STREAMING: Refers to
..."
- S1.1: The taxonomy of a peer into a leecher or a seeder appears to be
absolute. In real swarms (BitTorrent), a peer trades chunks with
other peers, so it is a leecher but also a provider for certain
chunks. This eventuality is not considered here.
- S1.2.1, what is the implication of the prefix "[Peer Protocol]" in the
numbered steps shown? Is it a reference (using syntax like we use for
references), or is it implying that the protocol used by a peer in
these steps is the peer protocol? If so, why not put the RFC/I-D
number of the peer protocol there?
- S1.2.2, s/Once CONNECTed/Once connected/
- S2.2, what is an "action signal"? Perhaps easier to simply say that
"This Request message is used when ..." Same with "information
signal".
- S2.3.1, s/register on a tracker/register with a tracker/
- S3.1, "turning the definitions for JSON objects extensible." I cannot
quite parse that. Sorry.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-grow-bmp-15
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-grow-bmp-15
Reviewer: Vijay K. Gurbani
Review Date: Oct-14-2015
IETF LC End Date: Not known
IESG Telechat date: Oct-15-2015
This document is ready as a Proposed Standard with two minor nits.
Major: 0
Minor: 2
Nits: 0
Minor:
- S3.2,, first paragraph: "No message is ever sent from the monitoring
station to the monitored router."
You mean "No BMP message is ever sent from the monitoring station to
the monitored router."? I suspect that the monitoring station can send
TCP messages (SYN, ACK, etc.) to the monitored router in order to open
up the TCP connection, no?
- S3.2, last paragraph: "If the monitoring station intends to end or
restart BMP processing, it simply drops the connection, optionally
with a Termination message."
The monitoring station cannot send a (BMP?) message to the monitored
router, right? If so, I don't understand the utility of the
Termination method above.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-precis-mappings-11
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-precis-mappings-11
Reviewer: Vijay K. Gurbani
Review Date: Sep-02-2015
IETF LC End Date: Not known
IESG Telechat date: Sep-03-2015
This document is ready as an Informational.
Major: 0
Minor: 0
Nits: 1
Nits:
- S2, second to last paragraph. Is "RECOMMENDED" as in rfc2119? If so,
please put rfc2119 in the references.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-sipcore-refer-explicit-subscription-02
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-sipcore-refer-explicit-subscription-02
Reviewer: Vijay K. Gurbani
Review Date: Jun-25-2015
IETF LC End Date: Not known
IESG Telechat date: Jun-25-2015
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-mip4-multiple-tunnel-support-12
On 05/15/2015 12:42 PM, Henrik Levkowetz wrote:
This is Mobile-IP-specific terminology, and has a well-known and precise
meaning within this area. It is necessary to specify if an extension is
skippable or non-skippable -- it determines both the numeric range from
which the extension number must be allocated, and how the extension must
be processed.
Henrik: Ah, I see. I was not aware of this usage, but since it is an
established practice in the community then we are golden. Thanks for
clarifying.
[...]
> Suggested text:
>
> When a mobile node registers multiple bindings with its home
> agent, each using a different care-of address, then each of those
> bindings are given a unique identifier.
Looks good to me.
Perfect. Thanks for attending my comments. I don't have any more.
Have a nice weekend.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-mip4-multiple-tunnel-support-12
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mip4-multiple-tunnel-support-12
Reviewer: Vijay K. Gurbani
Review Date: May-15-2015
IETF LC End Date: May-25-2015
IESG Telechat date: Not known
This document is ready as an Experimental Standard. A couple of points
below need addressing, though.
Major: 0
Minor: 2
Nits: 1
Minor:
1/ S4.1, second paragraph: "This extension is a non-skippable extension
and MAY be added by the mobile node to the Registration Request
message."
Two comments.
First, does "non-skippable" mean "MUST be present"? If so, why "non-
skippable"? At least I have not seen such a phrase in an IETF
document before. My suggestion would be to simply say that "This
extension MUST be present and ..."
Which brings us to the second comment.
"... and MAY be added by the mobile node ..." This extension is
"non-skippable" (?) but a mobile node MAY add it. If the extension
is "non-skippable", then why the MAY?
Furthermore, if the intent is for some other entity to add this
extension if the mobile node does not (hence the justification of
MAY), then you should spell out who this entity is. (Sort of
how you do it in S4.2, second paragraph, which contains almost
identical language to above without the qualifying last phrase
that informs the reader who will add the extension if not the
mobile node.)
2/ S4.2, second paragraph: Consider changing the "non-skippable"
to "MUST be present" (c.f., above comment).
Nits:
1/ S2.2, the following sentence does not read well:
A mobile node, when it registers multiple bindings with its home
agent, each using different care-of addresses, then each of those
bindings are given a unique identifier.
Suggested text:
When a mobile node registers multiple bindings with its home
agent, each using a different care-of address, then each of those
bindings are given a unique identifier.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-mpls-ldp-ipv6-15
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mpls-ldp-ipv6-15
Reviewer: Vijay K. Gurbani
Review Date: Feb-04-2015
IETF LC End Date: Unknown
IESG Telechat date: Feb-05-2015
This document is ready as a Proposed Standard.
Major: 0
Minor: 1
Nits: 1
Minor: 1
1/ In Section 3, it appears that the second paragraph ("This rule ...
updated rule:") is modifying rfc5036 to use the new text given
below the quoted paragraph.
However, I am not sure whether this is normative update or simply
a suggestion. In the second paragraph, the authors write that,
"Hence, it is reasonable to say ..." What does "reasonable" mean?
Does it mean that rfc5036 is updated authoritatively with the
suggested text or simply that rfc5036 text need not be updated but
the text in this draft should be considered.
Nits:
1/ I am not sure what portions of this draft update rfc6720...
Perhaps item (8) in Section 1, but am not sure.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Second last call review of draft-ietf-bmwg-sip-bench-meth
may sacrifice some
accuracy for speed. Such algorithms are for further study.
Nits/editorial comments:
---
IDNits requests that the code in Appendix A be preceded by a line and terminated by a line.
Sec. 3 para 2 last line: s/arrangements/arrangement/
Got it. Thanks!
Next para: spell out EA as presumably "Emulated Agents" on first
use?Term is from the terminology document.
Done.
Add and around the pseudo-code in 4.10.
Reference [I-D.sip-bench-term] is now dated July, 2014 (version -11).
Good catch. Updated.
I will skip the and nits, if it is okay with
you.
The results will show up in -12 that will be released shortly. Thanks
a lot, Tom, for your insights and feedback on this work.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Second last call review of draft-ietf-bmwg-sip-bench-meth
On 10/30/2014 10:57 AM, Tom Taylor wrote:
Do you need pseudo-code for Newton's Method, to see how it works. My
experience was that 3-4 iterations would get convergence.
Tom: Thanks. I will take a look at the URL you provided. The code
should be easy.
I will get back to you.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-rtcweb-data-channel-12
On 10/30/2014 07:15 AM, Michael Tuexen wrote:
Right. However, we wanted to make sure that there is no assumption
on the number of concurrent RTP flows. There are scenarios where
you will have no concurrent flow, scenarios where you have some,
but they are inactive, and also scenarios where you have concurrent
active RTP flows.
Michael: Thanks for the clarification.
In that case, perhaps a blanket statement outlining the above assumption
may suffice. Something like a sentence in the beginning of S3.1:
"The use cases below do not make any assumptions on the presence (or
absence) of SRTP media sessions, nor do they make any assumptions
on the state (active, inactive) of the SRTP sessions (if present)."
I will let you edit it as you see fit if you think it is worth adding
it in. If not, no worries.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Second last call review of draft-ietf-bmwg-sip-bench-meth
On 10/30/2014 04:29 AM, Jari Arkko wrote:
Thanks for the review, Tom. Was there an answer to the questions or
edits?
Jari: I have not got back to Tom regarding the edits yet as I was
waiting for IESG review to be done. I was planning to then attend
to both the Gen-ART and IESG comments on the drafts.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-rtcweb-data-channel-12
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-rtcweb-data-channel-12
Reviewer: Vijay K. Gurbani
Review Date: Oct-29-2014
IETF LC End Date: Oct-23-2014
IESG Telechat date: Oct-30-2014
This document is ready as a Proposed Standard.
Major: 0
Minor: 1
Nits: 1
Minor: 1
- S3.1, U-C 1: Why is it important to specify tha "there may be no
SRTP media channels, or all SRTP media channels may be inactive"?
It seems to me that all you care about is data channels, not
media channels. As such, retaining the last phrase ("there may also
be reliable data channels in use") suffices, no?
(Same comment for S3.2, U-C 3).
(Same comment for S4, Req. 1. This makes me wonder if I am missing
something germane here with respect to you listing the availability
or unavailability of SRTP media streams/channels. If so, please
let me know.)
Editorial nits:
- S6.4, opening paragraph:
s/One strong wish is/It is advantageous/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-6lo-ghc-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-6lo-ghc-04
Reviewer: Vijay K. Gurbani
Review Date: Sep-11-2014
IETF LC End Date: Ended
IESG Telechat date: Sep-18-2014
This document is ready as a Proposed Standard. I reviewed -03 and my
comments from that have been fixed in -04. I have no more comments.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-6lo-ghc-03
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-6lo-ghc-03
Reviewer: Vijay K. Gurbani
Review Date: Aug-22-2014
IETF LC End Date: Aug-29-2014
IESG Telechat date: Not scheduled yet
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 1
Editorial nits:
- S1.4, second line: s/in them the/in them, the/
third line: s/formally speaking,/formally,/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-trill-active-active-connection-prob-05
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-trill-active-active-connection-prob-05
Reviewer: Vijay K. Gurbani
Review Date: Jul-07-2014
IETF LC End Date: Jul-14-2014
IESG Telechat date: Not scheduled yet
This document is ready as an Informational.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-hip-rfc5202-bis-05
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-hip-rfc5202-bis-05
Reviewer: Vijay K. Gurbani
Review Date: Jun-24-2014
IETF LC End Date: Not known
IESG Telechat date: Jun-26-2014
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-eman-energy-aware-mib-15
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-eman-energy-aware-mib-15
Reviewer: Vijay K. Gurbani
Review Date: Jun-23-2014
IETF LC End Date: Jun-30-2014
IESG Telechat date: Not known.
This document is ready as a Proposed Standard.
A couple of nits can be fixed; more information below.
Major: 0
Minor: 0
Nits: 2
Nits
- S4, third paragraph:
s/and secondly on identification, context/on identification, and
context/
- S5.4, third paragraph: spacing appears to be off since the relation-
ships appear distended to the left, beyond the margin.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-06
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy-06
Reviewer: Vijay K. Gurbani
Review Date: May-7-2014
IETF LC End Date: Not known.
IESG Telechat date: May-15-2014
This document is ready as a Proposed Standard; I had reviewed -05 and
all of my comments from there have been addressed in -06.
I have no further comments.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-mpls-ldp-hello-crypto-auth-05
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mpls-ldp-hello-crypto-auth-05
Reviewer: Vijay K. Gurbani
Review Date: May-9-2014
IETF LC End Date: May-21-2014
IESG Telechat date: Not known
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
On 04/17/2014 11:13 AM, Lizhong Jin wrote:
- Section 7, paragraph 2: Okay to use MD5? Or something stronger...?
[Lizhong] the MD5 will follow the security consideration in
[I-D.ietf-pwe3-iccp] where "SHOULD" is used. And the security section
has been proposed by SEC-Dir to change as below: [...]
Lizhong: No worries; I just wanted to make sure that enough eyeballs had
paid attention to MD5, and it appears that is the case.
Thanks for accepting the rest of the nits.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
Reviewer: Vijay K. Gurbani
Review Date: Apr-17-2014
IETF LC End Date: Apr-24-2014
IESG Telechat date: Not known.
This document is ready as a Proposed Standard but has some nits and a
minor issue that should be looked at.
Major: 0
Minor: 1
Nits: 7
Minor:
- Section 7, paragraph 2: Okay to use MD5? Or something stronger...?
Nits:
- Section 1, paragraph 1:
s/is to provide/provides/
- Section 1, paragraph 2:
s/options introduced./options are introduced./
- Section 3: What is an "ASBR"? If it is a well-known term in the
domain, I suspect you don't need to expand it ...
- Section 3: s/agreements(SLAs)./agreements (SLAs).
- Section 7, first paragraph: s/will have/has/
- Section 7, second paragraph:
s/ICCP is now/If ICCP is/
- Section 7: You use "pseudowire" here whereas in most of the
remaining document you used "PW". You may want to be consistent.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-appsawg-rrvs-header-field-09
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-appsawg-rrvs-header-field-09
Reviewer: Vijay K. Gurbani
Review Date: Mar-27-2014
IETF LC End Date: Not known
IESG Telechat date: Mar-27-2014
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-melnikov-smime-msa-to-mda-03
On 02/25/2014 12:40 PM, Alexey Melnikov wrote:
Hi Vijay,
Thank you for your review.
Alexey: No worries.
I think this is a rather subjective topic: what one party (an
enterprise/organization) considers "good" practice might indeed not be
considered "good" by the sender. I am happy to remove "good" from the
sentence.
Perfect; that works for me.
Thanks for incorporating the remaining changes.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-melnikov-smime-msa-to-mda-03
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-melnikov-smime-msa-to-mda-03
Reviewer: Vijay K. Gurbani
Review Date: Feb-25-2014
IETF LC End Date: Mar-05-2014
IESG Telechat date: Unknown
I must say that this draft was written with implementors in mind.
This is very refreshing.
Major: 0
Minor: 0
Nits: 4
This document is ready as a Proposed Standard. Some minor nits follow:
Nits:
- S2.2, "Organizational policy and good security practice often
require that messages be reviewed before they are released to
external recipients." Here, I suspect that organizational policy may
require such a vetting but I would think that "good security practice"
would not. After all, unless a party is forced to do so (the
"organizational policy" part), why would one party willingly subject
its private communications to a third party before sending it
to the recipient? I would not consider that a third party reading
my messages a "good security practice". Therefore, I would take
the "good security practice" phrase out, unless of course, there is
some context to that phrase that I am not privy to.
- S3.3, first sentence: "A 'domain signature' is a signature generated
on behalf of a set of users in the domain the users are a member of."
This sentence appears rather, for the lack of a better word, clunky.
How about rewriting this as: "A 'domain signature' is a signature
generated on behalf of a set of users who belong to the specific
domain."
- S5, steps 3-A and 3-B: s/found then/found, then/
There are some more occurences of this, if you feel like it, you may
want to change these to have a comma as well.
- S7, first paragraph: s/permits masquerade./permits masquerading./
or, s/permits masquerade attacks./
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-abfab-arch-12
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-abfab-arch-12
Reviewer: Vijay K. Gurbani
Review Date: Feb-20-2014
IETF LC End Date: Unknown
IESG Telechat date: Feb-20-2014
Major: 0
Minor: 0
Nits: 0
This document is ready as an Informational.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART telechat review of draft-ietf-soc-overload-control-14.txt
On 02/02/2014 10:18 PM, Brian E Carpenter wrote:
Summary: Almost ready
Comments:
-
Minor Issue:
---
"5.6. Forwarding the overload control parameters
Overload control is defined in a hop-by-hop manner. Therefore,
forwarding the contents of the overload control parameters is
generally NOT RECOMMENDED and should only be performed if permitted
by the configuration of SIP servers. This means that a SIP proxy
SHOULD strip the overload control parameters inserted by the client
before proxying the request further downstream."
I think the reader should be reminded at this point that the proxy also
behaves as a client, so will immediately re-insert its own "oc" parameters.
(In fact it would be very odd if the proxy supported overload control
upstream but not downstream.) Vijay suggested: I can insert the following
sentence as the last sentence of the lone paragraph in S5.6:
"Of course, the proxy can add overload control parameters pertinent
to itself in the Via header it inserts in the request going
downstream."
This would be fine.
Brian: Thank you for the review. I have added the above sentence.
I will close the loop and ping you when I release -15 after the
quarantine period.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
On 01/31/2014 08:25 AM, Varun Singh wrote:
Hi Vijay,
Apologies for the tardiness, comments inline.
Varun: No worries. More inline.
In this particular case, we are worried about a side channel attack.
The attacker sends a late arriving packet (timestamp in the past) to
the receiver and if the receiver sends a discard report with the same
number of bytes as the payload of the injected packet, the attacker
may infer that no security processing was performed. If it observes
no discard report, it may infer that security procedures were
performed on the packet.
Ah, so you can trivially solve this problem by describing the attack in
the draft, much as you do above.
I think one of the reasons not to explicitly write about the threat
model is because there are several reason to use and not use
SRTP/AVPF. they are covered in ietf-avt-srtp-not-mandatory, and
implementors should read that document to make up their mind.
My reading of draft-ietf-avt-srtp-not-mandatory is that it does not
absolve RTP extension authors from talking about security, rather it
exhorts them to talk about the specific security problems exhibited
by their proposed extension and furthermore, elaborate how to address
such concerns.
I hope the chairs can clarify on how to proceed.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
On 01/24/2014 10:44 AM, Varun Singh wrote:
Nits: - S6, "In some situations, returning very detailed error
information (e.g., over-range measurement or measurement
unavailable) using this report block can provide an attacker with
insight into the security processing." I am not sure what you mean
by "security processing" here --- maybe you meant the byte discard
block leaks privacy of the user?
It is not necessarily privacy of the user, but a situation when the
receiver reports a packet as discarded and If the packet was
carefully crafted by an attacker, they infer something about the
security processing of the endpoint.
Varun: It was not immediately clear to me that your threat model when
you discuss this included the attacker mounting an active attack, but
regardless, the larger question of what you mean by "security
processing" remains --- who is doing the "processing" and how is the
"security" impacted?
If an attacker crafts a packet and sends it to the victim, who discards
it, then the attacker gets a XR Bytes Discarded report block, and at
best the attacker knows that the packet was discarded due to either
early arrival or late arrival (the 'E' bit). What is the "security
processing" insight that we are worried about here?
Furthermore, if the attacker is capable of mounting an attack such that
it can inject arbitrary packets to the victim, then the attacker is
either in a session with the victim (a session the victim can stop
at any time), or the attacker has usurped the channel between the
victim and the original participant that the victim was conversing
with. In both cases, I suspect that the damage done is more than the
attacker just getting back discard report blocks.
AFAIR the wording of the paragraph is adapted from other drafts
discussing discarded packets (RFC7097 and RFC7002) and with input
from sec-dir. That being said, if the wording can be made more clear,
I'm happy to incorporate the proposal.
I would have had the same questions of rfc7097 or rfc7002 if I had been
chosen to Gen-ART review them :-)
I think you need to motivate your threat model in S6 to determine the
mitigation strategies where SRTP/SAVPF will help. You can discuss this
with your chair or your friendly sec-dir personnel and if they
indicate that no threat model is needed, then please go ahead with the
draft. Gen-ART reviews are advisory in nature anyway. However, since
I was confused on reading the section and remain so after our brief
email exchange, I think some text added on the motivation may be helpful
to future readers (and implementers) of the extension.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
Reviewer: Vijay K. Gurbani
Review Date: Jan-24-2014
IETF LC End Date: Feb-04-2014
IESG Telechat date: Unknown
Major: 0
Minor: 0
Nits: 1
This document is ready as a Proposed Standard.
Nits:
- S6, "In some situations, returning very detailed error information
(e.g., over-range measurement or measurement unavailable) using this
report block can provide an attacker with insight into the security
processing." I am not sure what you mean by "security processing"
here --- maybe you meant the byte discard block leaks privacy of the
user?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-l2vpn-evpn-req-06
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-l2vpn-evpn-req-06
Reviewer: Vijay K. Gurbani
Review Date: Jan-21-2014
IETF LC End Date: Unknown
IESG Telechat date: Jan-23-2014
Major: 0
Minor: 0
Nits: 2
This document is ready for publication as an Informational.
The document is ready, most of the nits in the nit-list I had have
been addressed by the IESG during balloting. That said, the remaining
nits on my list are:
- The requirements in the Security Considerations section (R13 and R14)
are better put in Section 6 (Ease of Provisioning Requirements), no?
Is there something intrinsic to do with security on R13 and R14 that
they are put in the Security Considerations section? If there is, it
is not apparent to me.
- Grammar/language: Section 7, Requirement 9:
s/This gives rise to two/This results in two/
(Reason: "gives rise to" is probably best left to works of
fiction :-) )
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-shore-icmp-aup-09
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-shore-icmp-aup-09
Reviewer: Vijay K. Gurbani
Review Date: Jan-21-2014
IETF LC End Date: Unknown
IESG Telechat date: Jan-23-2014
Major: 0
Minor: 0
Nits: 0
This document is ready as a BCP.
I had reviewed -06 for Gen-ART and all of my comments in -06 have been
addressed. I have no further comments.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-soc-overload-control-14.txt
On 12/16/2013 07:21 PM, Brian E Carpenter wrote:
[...]
"Of course, the proxy can add overload control parameters pertinent
to itself in the Via header it inserts in the request going
downstream."
Let me know if that captures the intent of your comment.
Exactly. (I know it is stating the obvious, but it removes any doubt
from the reader's mind.)
Brian: Sure; I will add the suggested sentence in the next revision.
[...]
It's fine as long as you've thought about it. The official rule
is in RFC 2026: the document must 'stand as a complete and
understandable document with or without the reference to the
"Work in Progress".'
Indeed, I believe that draft-ietf-soc-overload-control passes that
metric, the reverse is not true. That is, the other two drafts,
namely draft-...-event-package and draft-...-rate-control need
draft-..-overload-control as a normative reference. I will inform
the WG about it.
Thanks, Brian.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-soc-overload-control-14.txt
Brian: Thank you for the review. Please see inline.
On 12/14/2013 04:10 PM, Brian E Carpenter wrote:
[...]
Minor Issues:
" The normative statements in this specification as they apply to SIP
clients and SIP servers assume that both the SIP clients and SIP
servers support this specification. If, for instance, only a SIP
client supports this specification and not the SIP server, then
follows that the normative statements in this specification pertinent
to the behavior of a SIP server do not apply to the server that does
not support this specification."
I don't find the second sentence useful. A useful sentence would be
a summary of what might go wrong if one side supports this specification
and the other doesn't. (As detailed in 5.10.2 for example.)
This blanket statement was added at the behest of the WG that preferred
such a statement in lieu of most sentences starting with "If a SIP
client supports ...".
"5.6. Forwarding the overload control parameters
Overload control is defined in a hop-by-hop manner. Therefore,
forwarding the contents of the overload control parameters is
generally NOT RECOMMENDED and should only be performed if permitted
by the configuration of SIP servers. This means that a SIP proxy
SHOULD strip the overload control parameters inserted by the client
before proxying the request further downstream."
I think the reader should be reminded at this point that the proxy also
behaves as a client, so will immediately re-insert its own "oc" parameters.
(In fact it would be very odd if the proxy supported overload control
upstream but not downstream.)
You are right that most, if not all, proxies would support overload
control on the client and server side. When the proxy acts as a server,
it will ask the upstream client to throttle messages if the proxy is
overloaded. When the proxy acts as a client, it is performing
throttling for the downstream server.
However, the pedantic notion in the text you quote is that the proxy
scrubs the overload control parameters from the Via header corresponding
to the upstream client, and adds overload control parameters in the Via
header the proxy inserts in the request going further downstream. To
make this notion clear, I can insert the following sentence as the last
sentence of the lone paragraph in S5.6:
"Of course, the proxy can add overload control parameters pertinent
to itself in the Via header it inserts in the request going
downstream."
Let me know if that captures the intent of your comment.
"13.2. Informative References"
I am not convinced that I-D.ietf-soc-overload-rate-control is correctly
classified as an Informative reference; for example see the citation
in section 5.3. It seems to me that an implementor would need to
consult the reference.
So, draft-ietf-soc-overload-rate-control is an informative
reference to this draft. This follows from the fact that draft-
ietf-soc-overload-control defines a framework where different classes
of overload control algorithms could be plugged in. Performing
overload control by using a rate-based algorithm is one such example.
Implementors of draft-ietf-soc-overload-control only implement the
loss-based traffic reduction algorithm, but the text exhorts them to
play better with other class of algorithms by pointing out that other
traffic reduction schemes may be used as well.
Your comment above actually triggered me to ensure that draft-ietf-soc-
overload-rate-control has a normative dependency on draft-ietf-soc-
overload-control. It does not. I will inform the author of the rate-
control draft.
Ditto I-D.ietf-soc-load-control-event-package (section 8).
Ditto as above.
Nit:
I hope this is a nit: the Last Call says it's for "Internet Standard"
but surely it's intended to be "Proposed Standard"?
Oh gosh, yes, indeed. It is supposed to be a PS.
Thanks for your time, Brian. I appreciate your comments.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-netmod-iana-timezones-03
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-netmod-iana-timezones-03
Reviewer: Vijay K. Gurbani
Review Date: Dec-13-2013
IETF LC End Date: Dec-17-2013
IESG Telechat date: Unknown
Major: 0
Minor: 0
Nits: 0
This document is ready for publication as a Proposed Standard.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-avt-srtp-not-mandatory-14
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-avt-srtp-not-mandatory-14
Reviewer: Vijay K. Gurbani
Review Date: Nov-26-2013
IETF LC End Date: Dec-06-2013
IESG Telechat date: Unknown
Major: 0
Minor: 0
Nits: 0
This document is ready for publication as an Informational RFC.
This is a well written document and I could not find anything lacking
that would be worth pointing out.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-shore-icmp-aup-06
On 10/28/2013 03:21 PM, Carlos Pignataro (cpignata) wrote:
Vijay,
Thanks for the review!
All your suggestions to fix nits are incorporated, and we have a revision
ready to be submitted when the I-D submission tool reopens.
In the mean time, please find attached HTML diffs addressing your comments.
Carlos: Works for me. Thanks for the changes.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-shore-icmp-aup-06
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-shore-icmp-aup-06
Reviewer: Vijay K. Gurbani
Review Date: Oct-25-2013
IETF LC End Date: Unknown
IESG Telechat date: Unknown
Major: 0
Minor: 0
Nits: 5
This document is ready as a BCP but has some nits that must be fixed.
Nits:
- S3, first paragraph: s/models after it./is modeled after it./
- S4, first paragraph could probably benefit from rewording. For
instance, there is an overt dependence on language like "that
terminology" and "what they are". I believe "that terminology"
refers to the understanding of the community on the terms
"management" and "control". Similarly "what they are" refers to
the same terms.
My suggestion would be to rewrite the latter portion of the para-
graph so it does not depend on "that" and "they" but instead
identifies the subject explicitly.
- S4, third paragraph: s/telecomm/telecommunications/
You have used "telecommunications" at other places, so it helps
to be consistent.
Same paragraph: it may be better to
s/and so on./and other similar artifacts./
"... and so on" is great for colloquial use but does not quite
carry into a standards document, IMHO.
- S4, paragraph 5, lines 3-4: s/management message/management messages/
- S4, paragraph 6, first bullet item: s/many, many/plethora of/
For same reasons having to do with colloquialism.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-trammell-ipfix-tcpcontrolbits-revision-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-trammell-ipfix-tcpcontrolbits-revision-04
Reviewer: Vijay K. Gurbani
Review Date: Oct-11-2013
IETF LC End Date: Unknown
IESG Telechat date: Unknown
This document is ready as an Informational.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-idr-rfd-usable-02
On 10/10/2013 08:53 AM, Randy Bush wrote:
more serious than usual bit-drop here due to overload. i cannot find
this review. should i be concerned? any bugs found?
Randy: Please see thread starting at
http://www.ietf.org/mail-archive/web/gen-art/current/msg08982.html
as i seem to have participated in that thread, it is even more
embarrassing than usual that it fell out of my head in less than a
month. thanks for reminding me, and apologies for being so absent
minded.
>
and again, thanks for the review. i gather you're happy?
Ecstatic!
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-idr-rfd-usable-02
On 10/09/2013 05:51 PM, Randy Bush wrote:
Vijay: Thanks for the review and for raising an issue - I am glad we
discussed it, and with the explanation I too agree that the document
can go ahead. I have balloted a No-Obj for this draft…
more serious than usual bit-drop here due to overload. i cannot find
this review. should i be concerned? any bugs found?
Randy: Please see thread starting at
http://www.ietf.org/mail-archive/web/gen-art/current/msg08982.html
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callback-10
Hannes:
I am happy with the changes outlined below. I am convinced they
make the document better. Thank you for attending to my comments.
On 09/27/2013 01:48 PM, Hannes Tschofenig wrote:
Hi Vijay,
I updated the draft to take your remarks into account.
I liked the security requirements text to the security threats section,
as you suggested.
I believe you have a point regarding the remark about the security
solution. The current description focuses on the PSAP but not on the UA.
I assumed that we essentially inherit the functionality from the
PhoneBCP document but that should be expressed somewhere.
So, I added the following section to the draft:
The approach for dealing with implementing the security requirements
described in Section 5.2 can be differentiated between the behavior
applied by the UA and by SIP proxies. A UA that has made an
emergency call will keep state information so that it can recognize
and accepted a callback from the PSAP if it occurs within a
reasonable time after an emergency call was placed, as described in
Section 13 of [RFC6443]. Since UA considerations are described
already in [RFC6443] as well as in [RFC6881] the rest of this section
focuses on the behavior of SIP proxies.
-
What do you think about that addition? Do you think it addresses your
concern?
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callback-10
e able to
deliver the callback from the PSAP to the UA, it is easy for the UA to
decide to accept it or not: If the UA never made an outgoing emergency
call, then any incoming call with callback marking is treated as spam.
If the UA made an outgoing emergency call, then an incoming call with
callback marking is accepted.
Please let me know what you think.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ccamp-gmpls-signaling-g709v3-12
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ccamp-gmpls-signaling-g709v3-12
Reviewer: Vijay K. Gurbani
Review Date: Sep-20-2013
IETF LC End Date: Sep-02-2013
IESG Telechat date: Unknown
This document is ready as an Proposed Standard.
Major: 0
Minor: 0
Nits: 0
I had reviewed -11 with nits [1], which have been fixed in -12.
I have no more comments.
[1] http://www.ietf.org/mail-archive/web/gen-art/current/msg08934.html
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callback-10
[Resending ... had the wrong address for Roger Marshall. Sorry. ]
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ecrit-psap-callback-10
Reviewer: Vijay K. Gurbani
Review Date: Sep-20-2013
IETF LC End Date: Sep-27-2013
IESG Telechat date: Unknown
This draft is basically ready for publication, but has a couple of
minor issues that should be fixed (or at least looked at) before
publication.
Major: 0
Minor: 2
Nits: 4 (to improve readability)
Minor:
- S5.2: Maybe I am missing something here, but I did not see any
proposed requirement as I read the text until this point. At least I
do not see a explicit requirement.
The text in S5.1 constitutes an implicit requirement in that it asks
the SIP UA to override user interface configurations when an incoming
call has "Priority: psap-callback" header AND the SIP UA has recently
placed a call to an emergency service. Is this the requirement you
allude to in the first sentence of S5.2? If so, may be better to
explicitly pose this as a requirement.
The second paragraph of S5.2 constitutes a separate requirement.
Is it worth spelling these out explicitly as requirements?
- S5.3, last paragraph: It seems to me that the SIP UA is the authority
insofar as it can maintain state that an emergency call was made a
short while ago. Consequently, it would seem beneficial to couple the
presence of the callback marking with this state and override local UA
behaviour.
At least, this alleviates the eventuality that somehow the VoIP
provider forgot to scrub the marking AND the UA never made an emergency
call (thereby allowing spam through).
Now, if it is your intent to keep the UA as stateless as possible, then
overriding local UA behaviour based on solely the callback marking is
fine. But I do not know what your assumptions are here with respect to
state maintained in the UA. So please determine if this approach of
asking UA to couple state information with the marking makes sense or
not. If not, feel free to disregard, but I did want to point it out.
Nits:
- S3, first paragraph: "As explained in Section 1 a SIP entity examines
an incoming PSAP callback by comparing the domain of the PSAP with the
destination domain of the emergency call."
Here, I would suggest adding a small phrase as follows:
s/destination domain of the emergency call./destination domain of the
outbound emergency call placed earlier./
- S3.1: s/synchronized as to state/synchronized,/
This improves readability since the text as it currently stand is hard
to parse.
- S3.3, second paragraph: s/Similarly to/Similar to/
- S3.5, first paragraph: s/later does leave/later leaves/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ecrit-psap-callback-10
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ecrit-psap-callback-10
Reviewer: Vijay K. Gurbani
Review Date: Sep-20-2013
IETF LC End Date: Sep-27-2013
IESG Telechat date: Unknown
This draft is basically ready for publication, but has a couple of
minor issues that should be fixed (or at least looked at) before
publication.
Major: 0
Minor: 2
Nits: 4 (to improve readability)
Minor:
- S5.2: Maybe I am missing something here, but I did not see any
proposed requirement as I read the text until this point. At least I
do not see a explicit requirement.
The text in S5.1 constitutes an implicit requirement in that it asks
the SIP UA to override user interface configurations when an incoming
call has "Priority: psap-callback" header AND the SIP UA has recently
placed a call to an emergency service. Is this the requirement you
allude to in the first sentence of S5.2? If so, may be better to
explicitly pose this as a requirement.
The second paragraph of S5.2 constitutes a separate requirement.
Is it worth spelling these out explicitly as requirements?
- S5.3, last paragraph: It seems to me that the SIP UA is the authority
insofar as it can maintain state that an emergency call was made a
short while ago. Consequently, it would seem beneficial to couple the
presence of the callback marking with this state and override local UA
behaviour.
At least, this alleviates the eventuality that somehow the VoIP
provider forgot to scrub the marking AND the UA never made an emergency
call (thereby allowing spam through).
Now, if it is your intent to keep the UA as stateless as possible, then
overriding local UA behaviour based on solely the callback marking is
fine. But I do not know what your assumptions are here with respect to
state maintained in the UA. So please determine if this approach of
asking UA to couple state information with the marking makes sense or
not. If not, feel free to disregard, but I did want to point it out.
Nits:
- S3, first paragraph: "As explained in Section 1 a SIP entity examines
an incoming PSAP callback by comparing the domain of the PSAP with the
destination domain of the emergency call."
Here, I would suggest adding a small phrase as follows:
s/destination domain of the emergency call./destination domain of the
outbound emergency call placed earlier./
- S3.1: s/synchronized as to state/synchronized,/
This improves readability since the text as it currently stand is hard
to parse.
- S3.3, second paragraph: s/Similarly to/Similar to/
- S3.5, first paragraph: s/later does leave/later leaves/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-idr-rfd-usable-02
Susan: Thanks for getting back to me. More inline.
On 09/06/2013 04:45 PM, Susan Hares wrote:
I was comfortable with this in the document. I believe authors need to be
comfortable with the document along with the WG.
The authors appear to be more cautions than the WG or RIPE who endorsed the
document.
Great. My intent was to bring attention to the sentence in the event
that it had escaped unscathed. Of course, from your response as well
as the follow up from Randy Bush, it appears that adequate deliberations
went into the thinking that allowed the sentence to appear.
Given all this, I am fine with moving ahead with the draft.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-idr-rfd-usable-02
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-idr-rfd-usable-02
Reviewer: Vijay K. Gurbani
Review Date: Sep-6-2013
IETF LC End Date: Unknown
IESG Telechat date: Unknown
This draft is basically ready for publication, but has one minor issue
that should be fixed (or at least looked at) before publication.
Major: 0
Minor: 1
Nits: 0
Minor issue:
- This is a document on the standards track. Therefore, it is rather
disconcerting to see the following statement in the draft (end of
Section 2): "[This document] is not a panacea, nor is it a deep and
thorough approach to flap reduction."
I understand the panacea part, it is the trailing phrase that I want
to draw attention to.
Now, I am not a routing expert so I would presume that despite the
exhortations above, the chairs of the WG and the AD have looked at
the document and are comfortable with the sentence I have pointed out.
(Sorry if it has been discussed in the WG.) Assuming that is the
case, I am happy to proceed with this document. Assuming it is not,
would an Experimental designation be appropriate?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ccamp-gmpls-signaling-g709v3-11
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ccamp-gmpls-signaling-g709v3-11
Reviewer: Vijay K. Gurbani
Review Date: Aug-26-2013
IETF LC End Date: Unknown
IESG Telechat date: Unknown
This document is ready as an Proposed Standard.
Major: 0
Minor: 0
Nits: 1
Nits:
- S1, first paragraph: Expand "OTN" on first use. Also,
s/provided for [G709-2012]./provided for OTNs [G709-2012]./
The last substitution above is a general comment since this construct
appears multiple times in S1 and the rest of the document.
Essentially, you need a label before the reference itself. Making the
reference itself a label seems incongruent (at least to me). I am
filing this as a nit, so I will let you decide whether to change it or
not.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-bmwg-imix-genome-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-bmwg-imix-genome-04
Reviewer: Vijay K. Gurbani
Review Date: Apr-26-2013
IETF LC End Date: May-06-2013
IESG Telechat date: May-30-2013
This document is ready as an Informational. A couple of minor comments
that can benefit the draft below.
Major: 0
Minor: 2
Nits: 0
Minor:
- S1, 4th paragraph: "An IMIX suited for one networking device and
deployment will not be appropriate for another." I suspect the
variability of the packet sizes has to do with the vendor whose device
is being benchmarked. In other words, a constant, K, used as a packet
size by Vendor A does not mean that K can be used while benchmarking a
device by Vendor B. If so, it may be helpful to augment the quoted
sentence above by the phrase "because packet sizes differ across
different vendor devices."
- S3, "o Non-RFC2544 packet sizes ... in the table." --- Is this not
already covered in S4 (Custom IMIX)? When I read the quoted bullet
item, I immediately thought of some sort of an encoding scheme to
encode non standard packet sizes, which is what S4 does. Maybe I
am missing something?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-xrblock-rtcp-xr-burst-gap-discard-13
Reviewer: Vijay K. Gurbani
Review Date: Apr-19-2013
IETF LC End Date: Mar-15-2013
IESG Telechat date: Apr-25-2013
This document is ready as a Proposed Standard. One minor comment and
one nit below.
Major: 0
Minor: 1
Nits: 1
Minor:
- S2.1, the sentence, "A packet that arrives within this time window
but is too early or late to be played out or thrown away before
playout due to packet duplication or redundancy shall be regarded as
discarded." is hard to read and parse.
Clearly, if a packet arrives early, it will be buffered. Just as
clearly, if a packet arrives too late to be played out, it will be
discarded. Maybe you should break the offending sentence into two
separate sentences, one dealing with early arrival and the other
with late arrival.
Nits
- S1.1, last paragraph: s/in[RFC3611]./in [RFC3611]./
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-mpls-tp-ring-protection-05
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-mpls-tp-ring-protection-05
Reviewer: Vijay K. Gurbani
Review Date: Apr-09-2013
IETF LC End Date: Apr-18-2013
IESG Telechat date: Not known
This document is ready as an Informational. Some comments for
changes follow.
Major: 0
Minor: 0
Nits: 3
Nits:
- S1.1, bullet numbered 3: s/actionis/action is/
- S2, header "P2P Ring Protection": In the header, "P2P" probably
refers to "Point-to-Point" and not "Peer-to-Peer". It is okay
to leave it as such if you think that the readers in the MPLS
domain will interpret it as "Point-to-Point", but if you think
it will help to folks (like me) who do not normally work at the
network layer then it may be worth expanding the acronym out
in the header. (FWIW, I initially assumed "P2P" stood for
"Peer-to-Peer".)
- S2.1, s/mis-connectivity, should/mis-connectivity should/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-simple-simple-08
On 02/16/2013 06:21 AM, Jonathan Rosenberg wrote:
- S3.2, discussion of rfc3862: Does CPIM stand for "Common Presence and
Instant Messaging" or does it stand for "Common Profile for Instant
Messaging", as expanded in rfc3862 itself?
Actually, the title of RFC3862 is in fact "Common Presence and Instant
Messaging", even though the message format it defines is common profile
for instant messaging. As such, I have kept this since the acronym
refers to the title of the spec.
Jonathan: Sure, no worries.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-simple-simple-08
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-simple-simple-08
Reviewer: Vijay K. Gurbani
Review Date: Feb-11-2013
IETF LC End Date: Feb-14-2013
IESG Telechat date: Not known
This document is ready as an Informational. Some comments for
changes follow.
Major: 0
Minor: 2
Nits: 1
Minor:
- S2.1, discussion of rfc3265: RFC3265 is now made obsolete by rfc6665,
I believe an update is appropriate here as well as other places where
a reference to rfc3265 is made.
Additionally, a reference to rfc3856 will be appropriate when
we first talk about presence as a SUBS/NOT event package i.e.,
s/Presence is defined as an event package/Presence is defined as
an event package [RFC3865]/
- S3.2, discussion of rfc3862: Does CPIM stand for "Common Presence and
Instant Messaging" or does it stand for "Common Profile for Instant
Messaging", as expanded in rfc3862 itself?
Nits:
- Abstract, perhaps better for a standard document to use more
formal language and:
s/It breaks them up into categories/It categorizes the specifications/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-rtgwg-ordered-fib-09
On 02/01/2013 01:22 PM, Stewart Bryant wrote:
Some elements are scattered though the IETF meeting archives as this
was discussed in the RTGWG meetings.
However some aspects are too sensitive to publish as we looked
at the expected behaviour on operational networks complete with
costs.
Stewart: Sure, I can understand the need for sensitivity.
Would be nice to have a canonical topology stripped of any sensitive
network configuration, but I realize that this is not a necessity nor
a prerequisite for moving the draft ahead. That is why I indicated
this as a nit.
However, the engineer in me likes to see papers with results
that can easily be duplicated by others working in the domain.
That said, please move ahead with the draft from my end. I have
no further comments.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-udp-encaps-09
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-tsvwg-sctp-udp-encaps-09
Reviewer: Vijay K. Gurbani
Review Date: Fev-01-2013
IETF LC End Date: Jan-22-2013
IESG Telechat date: Feb-07-2013
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 0
I reviewed -07 and have no further comments on -09.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-rtgwg-ordered-fib-09
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-rtgwg-ordered-fib-09
Reviewer: Vijay K. Gurbani
Review Date: Feb-01-2013
IETF LC End Date: Unknown
IESG Telechat date: Feb-07-2013
This document is ready as an Informational.
Major: 0
Minor: 0
Nits: 1
Nits: It is mentioned in Section 2 that, "The technology described in
this document has been subject to extensive simulation using real
network topologies and costs and pathological convergence behaviour."
If the simulations were published in an archival format conference
proceeding or if the results are publicly available elsewhere, it may
make sense to provide appropriate references.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-oauth-assertions-10
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-oauth-assertions-10
Reviewer: Vijay K. Gurbani
Review Date: Jan-25-2013
IETF LC End Date: Unknown
IESG Telechat date: Feb-07-2013
This document is ready as a Proposed Standard (i.e., no change from
my original review of -08).
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-udp-encaps-07
On 01/11/2013 02:33 PM, Michael Tuexen wrote:
It is hard for me to suggest a concrete text improvement which clarifies
the current text and also provides the necessary flexibility. Could you
suggest some text?
Michael: It could be that in the end any text we add may lead to other
ambiguities --- so maybe we leave things as-is. Since we are
essentially at the transport layer, let's just talk in terms of ports,
which are the canonical identifiers at that layer.
So I prefer to leave it as it is.
Sure.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-udp-encaps-07
On 01/11/2013 11:11 AM, Michael Tuexen wrote:
thank you very much for your comments.
Michael: Thank you for attending to my comments. Please see inline.
- S4.1, second paragraph: I suspect that the expectation is that
the SCTP stack uses a single local UDP port number for
*all local interfaces*, right? As written currently, the qualifier
for "all local interfaces" is missing --- maybe it is assumed? If so,
better to state explicitly.
The text says
Each SCTP stack uses a single local UDP encapsulation port number as
the destination port for all its incoming SCTP packets.
So we are not referring to any kind of interfaces. When building the
stack in userland, you might not deal with interfaces. You might
bind to some addresses. So it might make sense not to explicitly
deal with the notion on interfaces.
Well, yes, but the larger point I was trying to make was whether the
same port number is expected to be bound to multiple local addresses,
which is what we get through using INADDR_ANY when filling in the
sin_addr.s_addr component before the bind() system call during coding
servers for other transports. It seems that the answer would be yes,
since the semantics are similar to UDP and TCP ... so maybe it is okay
not to explicitly deal with interfaces.
- S5, second paragraph ("Please note that this section is informational
only.") --- I am not sure the value of this sentence. The draft itself
is targeted as a standards track document, so it comes as a surprise
that a certain section is to be exempted from normative language. How-
ever, since there isn't any normative language (as per rfc2119) in the
remainder of S5, why bother with informing the reader that this section
is informational? My suggestion would be to simply remove the
offending sentence to decrease any ambiguity.
Section 5 describes the Socket API. It extends RFC 6458, which describes
the socket API and is an informational RFC. Also section 10 of RFC 4960
which describes a generic API is "for illustrative purposes".
Please note that also section 6 of RFC 6525 describing the corresponding
socket API extensions contains the same sentence
"Please note that this section is informational only."
So for consistency, I would prefer to keep it as it is.
That is certainly your prerogative; although it seems to me that maybe
saying that "this section is for illustrative purposes only" a la
rfc4960 is better. But I will certainly leave it to your sound
discretion.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-udp-encaps-07
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-tsvwg-sctp-udp-encaps-07
Reviewer: Vijay K. Gurbani
Review Date: Jan-11-2013
IETF LC End Date: Jan-22-2013
IESG Telechat date: Feb-07-2013
This document is ready as a Proposed Standard.
Major: 0
Minor: 2
Nits: 1
Minor:
- S4.1, second paragraph: I suspect that the expectation is that
the SCTP stack uses a single local UDP port number for
*all local interfaces*, right? As written currently, the qualifier
for "all local interfaces" is missing --- maybe it is assumed? If so,
better to state explicitly.
- S5, second paragraph ("Please note that this section is informational
only.") --- I am not sure the value of this sentence. The draft itself
is targeted as a standards track document, so it comes as a surprise
that a certain section is to be exempted from normative language. How-
ever, since there isn't any normative language (as per rfc2119) in the
remainder of S5, why bother with informing the reader that this section
is informational? My suggestion would be to simply remove the
offending sentence to decrease any ambiguity.
Nits:
- S3.1, third paragraph: I would suggest "s/user-land/user space".
It is better to be academic than colloquial here.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-oauth-assertions-08
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-oauth-assertions-08
Reviewer: Vijay K. Gurbani
Review Date: Dec-18-2012
IETF LC End Date: Dec-24-2012
IESG Telechat date: Unknown
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-salgueiro-vcarddav-kind-device-06
On 11/30/2012 11:12 AM, Pete Resnick wrote:
[...]
Do I understand correctly that you simply want to delete the sentence,
"Additionally, [RFC6473] has defined a value of "application" for the
KIND property to represent software applications."?
Pete: Yes.
I can put the two changes (this one, and the one suggest by PSA as
edited by Joe) in the RFC Editor notes of the tracker for the moment.
Who know, maybe a miracle will occur and these will be the only changes
between Last Call and IESG Evaluation. :-)
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-salgueiro-vcarddav-kind-device-06
Gonzalo: Please see inline.
On 11/30/2012 10:27 AM, Gonzalo Salgueiro wrote:
1. I'm fine with the suggested edit and will update the next version
(after IETF LC) with the suggested changes.
2. FN is a well-known identification property for vCards and does
expand to "Full Name". Even in RFC 6350 it doesn't appear to be
expanded, so I'll likely continue that trend and simply add a
reference section 6.2.1 of RFC 6350 after the usage of FN to help the
uninitiated in vCards. Is that OK with you?
That sounds good. Thanks for attending to my comments.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-salgueiro-vcarddav-kind-device-06
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-salgueiro-vcarddav-kind-device-06
Reviewer: Vijay K. Gurbani
Review Date: Nov-30-2012
IETF LC End Date: Dec-26-2012
IESG Telechat date: Unknown
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 2
Nits:
1/ S1: The value "thing" sort of creeps up on you in the second
paragraph. Upon further reading, it becomes more apparent that
during the WG discussions "thing" was a meta-value (or super-
class) and that "application" and "device" appear to be sub-
classes (or specific values) of "thing"s.
Furthermore, rf6473 already defined "application" and that this
particular draft is now defining "device".
To better impart this information, I would suggest the following
simple modification
OLD:
...Working Group defined values of "individual", "org", "group", and
"location" for the KIND property. Additionally, [RFC6473] has
defined a value of "application" for the KIND property to represent
software applications.
During working group discussion of the document that became
[RFC6473], consideration was given to defining a more general value
of "thing", but it was decided to split "thing" into software
applications and hardware devices and to define only the
"application" value at that time
NEW:
...Working Group defined values of "individual", "org", "group", and
"location" for the KIND property.
During working group discussion of the document that became
[RFC6473], consideration was given to defining a more general value
of "thing", but it was decided to split "thing" into software
applications and hardware devices and to define only the
"application" value at that time
2/ S2, top of page 4: "FN" probably expands to "Full Name". If it is
an accepted practice to use "FN" in your domain, then you can leave
it unexpanded. If not, then an expansion may help the general reader
(like me) who may think what "FN" is. (The rest of the properties
listed on page 4 and 5 appear to be self-explanatory).
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-pkix-rfc5280-clarifications-10
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-pkix-rfc5280-clarifications-10
Reviewer: Vijay K. Gurbani
Review Date: Oct-16-2012
IETF LC End Date: Not known
IESG Telechat date: Oct-25-2012
This document is ready as a Proposed Standard.
Major: 0
Minor: 0
Nits: 2
Nits:
- S1: The fourth paragraph should be put right underneath the second
paragraph since the former continues discussion started by the latter.
- S1: Last paragraph --- it will be good to provide some documentation
regarding the "observed attacks". Especially a link to relevant papers
of archival quality discussing the attacks will be helpful. If the
attacks are related to the Diginotar and Comodo break-ins, then there
is an archival paper [1] at a reasonably high level from IEEE that
discusses this and provides a starting point for those who want to
learn more.
[1] Neal Leavitt, "Internet security under attack: The undermining of
digital certificates," pp. 17-20, IEEE Computer, December 2011.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-precis-problem-statement-08
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-precis-problem-statement-08
Reviewer: Vijay K. Gurbani
Review Date: Oct-16-2012
IETF LC End Date: Oct-23-2012
IESG Telechat date: Not known
Summary: This draft is ready as an Informational.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ospf-prefix-hiding-05
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ospf-prefix-hiding-05.
Reviewer: Vijay K. Gurbani
Review Date: Aug-13-2012
IETF LC End Date: July-6-2012
IESG Telechat date: Aug-16-2012
Summary: This draft is ready as a Proposed Standard.
I had reviewed the previous version (-04) and found it ready.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-opsawg-automated-network-configuration-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-opsawg-automated-network-configuration-04
Reviewer: Vijay K. Gurbani
Review Date: Aug-13-2012
IETF LC End Date: Aug-15-2012
IESG Telechat date: Aug-16-2012
This draft is on the right track but has open issues, described in
the review.
Major: 0
Minor: 5
Nits: 4
Minor:
1/ S1, paragraph 2: The use of the phrase "...how to implement things
properly," is too colloquial for a standards document (even though the
draft is targeted as an Informational). I would suggest to rewrite the
phrase with more information on what these "things" are.
2/ S1, similar comment for issue (b), it is too colloquial. I would
suggest rewording to something like the following: "network equipment
vendors introducing who would like to ensure a smooth delivery of many
devices with new features"
3/ S1, paragraph 4 --- I suspect that simply expanding eNodeB to
"Evolved Node B" and referencing the appropriate standard body's
document describing the role of eNodeB should suffice.
4/ S3, second paragraph: "let us agree" is, again, more colloquial than
standards-oriented prose. Maybe a good thing to do would be to define
"configuration data", "configuration server", "joining device" and
others in a terminology section (either as a subsection in S3 or as a
section of its own). You already have a good collection of such
terminology definitions at the beginning of S3.
5/ S5.4, page 12, while discussing lack of URNs for SAN to carry a MAC:
one way to carry a MAC in SAN is to use the otherName field as
discussed in rfc5280. S4.2.1.6. I suspect that you have evaluated
this option but decided against it. If so, it will be good to list it
as an indication of the reasons why you do not think this option will
work.
Nits:
1/ S1, s/nodes, in a Wi-Fi rather/nodes in a Wi-Fi rather/
2/ S3, in "Pre-configuration": I suspect that the "certificate"
mentioned there pertains to an X.509 certificate. If so, please
make it apparent.
3/ S5.1: s/non-IETF protocols only./non-IETF protocols./
4/ S5.4: s/identity built in/identity/
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ospf-hybrid-bcast-and-p2mp-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ospf-hybrid-bcast-and-p2mp-04
Reviewer: Vijay K. Gurbani
Review Date: Aug-13-2012
IETF LC End Date: Unknown
IESG Telechat date: Aug-16-2012
Summary: This draft is ready as a proposed standard.
Major: 0
Minor: 0
Nits: 1
Nits:
1/ S1, second paragraph, 4th line: s/all all/all/
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-karp-threats-reqs-05
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-karp-threats-reqs-05
Reviewer: Vijay K. Gurbani
Review Date: Jul-18-2012
IETF LC End Date: Unknown
IESG Telechat date: Jul-19-2012
Summary: This draft is ready as an Informational.
Major: 0
Minor: 0
Nits: 4
Nits:
- S1, last paragraph has a spurious ":
s/in their usage."/in their usage.
- S1.1, in the description of Traffic Key: the second sentence is
a run on sentence and could do with an extra comma (,) as follows:
s/device configuration no data/device configuration, no data/
- S2.2, first paragraph:
s/yet-best- security-possible/yet-best-security-possible/
- S3.2, under "INFERENCE", there are six sub-bullets. The labels
on all of them except the last one are capitalized. Any reason
for the discrepancy?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ospf-prefix-hiding-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ospf-prefix-hiding-04.
Reviewer: Vijay K. Gurbani
Review Date: Jun-25-2012
IETF LC End Date: July-6-2012
IESG Telechat date: Not known
Summary: This draft is ready as a Proposed Standard.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-xrblock-rtcp-xr-meas-identity-06
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-xrblock-rtcp-xr-meas-identity-06
Reviewer: Vijay K. Gurbani
Review Date: May-31-2012
IETF LC End Date: June-14-2012
IESG Telechat date: Not known
Summary: This draft is ready as a Proposed Standard; it has one minor
comment that should be fixed before publication.
Major: 0
Minor: 1
Nits: 0
Minor:
- In S6, the text says that "... the use of security mechanisms with
RTP, as documented in Section 9 of [RFC3550] SHOULD apply."
I am puzzled by the normative language here. Won't it be more proper
to simply say that "... the use of security mechanisms with RTP, as
documented in Section 9 of [RFC3550] apply."
The use of SHOULD seem to indicate that there are certain cases
during measurement reporting where the security considerations do not
apply. Surely you do not mean that, do you?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-nfsv4-pnfs-block-disk-protection-02
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-nfsv4-pnfs-block-disk-protection-02
Reviewer: Vijay K. Gurbani
Review Date: May-24-2012
IETF LC End Date: June-06-2012
IESG Telechat date: Not known
Summary: This draft is ready as a Proposed Standard
Major issues: 0
Minor issues: 0
Nits/editorial comments: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-snell-atompub-tombstones-15
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-snell-atompub-tombstones-15
Reviewer: Vijay K. Gurbani
Review Date: May-18-2012
IETF LC End Date: Feb-21-2012
IESG Telechat date: May-24-2012
Summary: This draft is ready as a Proposed Standard
Major issues: 0
Minor issues: 0
Nits/editorial comments: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-ippm-reporting-metrics-08
On 05/08/2012 10:13 AM, Al Morton wrote:
Hi Vijay,
Thanks for your review, please see replies below.
Al: Thanks for indulging me. Points worth spending one more iteration
on are below.
I thought process *was* generic, but will try your suggested text.
Thanks.
Is "operations" sufficiently generic?
I think so; the term "operations" existed in your original writeup
and I simply reused it.
I think that might be the Loss CDF,
Ah, right.
but this is the Delay CDF when Lost Packets are assigned delay = +infinity.
OK.
Nits:
- S1: While characterizing the main audience, I am not sure what
"consumer" means --- is it synonymous with "user"? And if so, I
think that replacing consumer with user may be better. If these
terms are not synonymous, then please provide a definition (even a
loose one) of what a consumer is.
"user" is too vague and also has a strong precedent in the computer
networking context - we can add an adjective:
s/consumer/report consumer/
I tried to re-read the sentences with s/consumer/report consumer/, but
I must admit that I am none the wiser. Maybe s/consumer/audience/?
- S3.1, seems like a grammatical error in the sentence:
"We have calculated a waiting time above that should be sufficient
to differentiate between packets that are truly lost or have long
finite delays under general measurement circumstances, 51 seconds."
Probably better to rephrase as:
"We have calculated that under general measurement circumstances,
51 seconds is an appropriate length of time to differentiate between
packets that are truly lost from packets that are experiencing
long finite delays."
My grammar-checker accepted a slightly revised version,
with s/above/in section 4.1.1/
The original sentence seems odd --- the object of the calculated waiting
time (51 seconds) appears at the end of the sentence. By the time the
reader gets to the ", 51 seconds", he or she may have lost the context
of why 51 seconds is important.
- S5.1.2: In Figure 3, I would suggest using "+Inf" instead of
"+o0" to denote infinity. It took me a while to figure out that
the latter is an ASCII approximation to infinity.
So far, everybody else got it...
OK, no problem. Please do retain the original text.
Thank you for your time, Al!
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ippm-reporting-metrics-08
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ippm-reporting-metrics-08 Reviewer: Vijay K. Gurbani Review Date: May-08-2012 IETF LC End Date: April-11-2012 IESG Telechat date: May-10-2012 Summary: This draft is ready as an Informational but has some minor issues and nits that should be fixed before publication. Major issues: 0 Minor issues: 6 Nits/editorial comments: 5 Minor issues: - S3.1: I suspect that the metrics like packet loss and packet delay discussed in S3.1 are for hosts on the (I)nternet and not in a laboratory setting, yes? If so, it may be good to state this. - S4.1: I would mention at the end of the paragraph that you intend to fill the gap in RFC2680 by providing a reasonable value for the waiting time. - S4.1.1: In Figure 1, t_0 is probably the delay in the initial link before you get to the first router. If so, please make this explicit. - S4.1.1: Just curious --- you provide a rationale for the choice of link delay of 100ms and queue length of 100ms. But n=5 and L=4 seem to be magic numbers. I suspect that the choice of these is sound, but a couple of words on why the values of these variables are set to the ones shown would be good. - S5.1.1: In the two bullet items here, you posit that processes are spawned when an unexpected condition occurs. Why should this be a process? Why not a thread? Or a light-weight process? Or an event loop? My point is to stay away from well known and contextual words that dictate a specific architecture; i.e., the receiver spawns processes to handle an event. Better to be generic, something like the following (please modify as you see fit): OLD: o Packets that arrive within expected tolerance are handled by processes that remove headers, restore smooth delivery timing (as in a de-jitter buffer), restore sending order, check for errors in payloads, and many other operations. o Packets that do not arrive when expected spawn other processes that attempt recovery from the apparent loss, such as retransmission requests, loss concealment, or forward error correction to replace the missing packet. NEW: o Packets that arrive within expected tolerance are handled by removing headers, restoring smooth delivery timing (as in a de-jitter buffer), restoring sending order, checking for errors in payloads, and many other operations. o Packets that do not arrive when expected lead to an attempted recovery from the apparent loss, such as retransmission requests, loss concealment, or forward error correction to replace the missing packet - S5.1.2: Figure 3 --- if I understand the surrounding text for Figure 3 correctly, then to show a "small fraction of packets are lost", the CDF curve should be asymptotic to the Y-axis and then become stable at the Y=1 value (i.e., be asymptotic to it). We want to denote that almost 100% of the packets exhibit a loss close to 0. Nits: - S1: While characterizing the main audience, I am not sure what "consumer" means --- is it synonymous with "user"? And if so, I think that replacing consumer with user may be better. If these terms are not synonymous, then please provide a definition (even a loose one) of what a consumer is. - S3.1, seems like a grammatical error in the sentence: "We have calculated a waiting time above that should be sufficient to differentiate between packets that are truly lost or have long finite delays under general measurement circumstances, 51 seconds." Probably better to rephrase as: "We have calculated that under general measurement circumstances, 51 seconds is an appropriate length of time to differentiate between packets that are truly lost from packets that are experiencing long finite delays." - S4.1.1: Right before Figure 1, you define D. My suggestion would be to replace the text: "The normal path delay across n hops without encountering a loop, D, is" with "The normal path delay, D, across n hops without encountering a loop is" Here, "D" is qualifying the delay, not the loop. So it is best close to the word "delay". - S5.1.2: In Figure 3, I would suggest using "+Inf" instead of "+o0" to denote infinity. It took me a while to figure out that the latter is an ASCII approximation to infinity. - S6.6: In the section heading, I would advise spelling out "Avail." completely. Truncating it as such serves no purpose that I could see and simply acts as a detraction. Thanks! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illi
[Gen-art] Gen-ART review of draft-ietf-avtext-rams-scenarios-04
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-avtext-rams-scenarios-04
Reviewer: Vijay K. Gurbani
Review Date: Apr-27-2012
IETF LC End Date: Not known
IESG Telechat date: May-10-2012
Summary: This draft is ready as an Informational.
Major issues: 0
Minor issues: 0
Nits/editorial comments: 5
Nits/editorials:
- S1: For readability, I would suggest the following change:
OLD:
... In scenarios where multiple RAMS sessions, each initiated
with an individual RAMS Request message to a different feedback
target, will be simultaneously run by an RTP receiver, they need to
be coordinated.
NEW:
... Close coordination is required for multiple RAMS sessions
simultaneously started by an RTP server, where each session
is initiated with an individual RAMS Request message to a different
feedback target.
- S2, second line: the use of the word "somewhow" just seems
wishy-washy here. Instead, I think it is better to say "... that
are in some manner associated with each other."
- S3.1: Instead of saying "We run ..." and "we want to ..." better
to say that "An individual RAMS sesson is run for each of the RTP
streams that requires rapid acquisition."
- S3.4, same problem: instead of saying "we have only one RTP
stream..." better to say "there is only one RTP stream ..."
- S6: Probably better to say that there are no new security attacks
made possible by the this draft, however, security considerations of
RFC6285 still apply. Or something to that effect.
Thanks!
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-appsawg-mime-default-charset-03
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-appsawg-mime-default-charset-03
Reviewer: Vijay K. Gurbani
Review Date: Apr-27-2012
IETF LC End Date: May-07-2012
IESG Telechat date: May-10-2012
Summary: This draft is ready as a Proposed Standard.
Major issues: 0
Minor issues: 0
Nits/editorial comments: 1
Nit: For better readability, I would suggest the following change in S1:
s/value used when it is not/value used when the parameter is not/
Other than that, it is ready to go.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-marf-spf-reporting-10
On 03/21/2012 10:45 AM, Barry Leiba wrote:
Thanks very much for the review, Vijay... but this document has been
through last call, the IESG, the telechat, and AD follow-up, and the
approval announcement was sent yesterday.
Barry: Indeed, and I must apologize for my tardiness. I have been
completely swamped. But I did want to be diligent and finish the docs
on my queue.
I'm glad you didn't find anything seriously wrong with it!
Agreed!
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-marf-spf-reporting-10
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-marf-spf-reporting-10
Reviewer: Vijay K. Gurbani
Review Date: Mar-21-2012
IETF LC End Date: Mar-14-2012
IESG Telechat date: March-15-2012 (*** Sorry for the delay ***)
Summary: This draft is ready as a Proposed Standard.
Major issues: 0
Minor issues: 0
Nits/editorial comments: 1
Nits:
- The referencing in this document seems odd. For example, normal
referencing would be:
As required by IANA [IANA-CONSIDERATIONS], ...
Here, the reference object is "IANA" and the reference is
"IANA-CONSIDERATIONS". xml2rfc creates a link from "IANA-
CONSIDERATIONS" to the References section.
However, this draft uses referencing as follows:
As required by [IANA-CONSIDERATIONS], ...
This essentially conflates the reference object ("IANA") with
the reference itself ("IANA-CONSIDERATIONS").
I suspect that this is a stylistic convention used by the authors,
so if they are happy with it then they can feel free to disregard
this comment.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-desruisseaux-caldav-sched-11
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-desruisseaux-caldav-sched-11
Reviewer: Vijay K. Gurbani
Review Date: Mar-21-2012
IETF LC End Date: Not known
IESG Telechat date: March-04-2012 (*** Sorry for the delay ***)
Summary: This draft is ready as a Proposed Standard.
Major issues: 0
Minor issues: 0
Nits/editorial comments: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-shin-augmented-pake-12
On 03/02/2012 12:43 AM, SeongHan Shin wrote:
Dear Vijay,
Thank you for your comments.
You can see all the changes in -13 version. [...]
Great! Thank you for taking care of the comments.
I have no further questions on -13.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-shin-augmented-pake-12
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-shin-augmented-pake-12
Reviewer: Vijay K. Gurbani
Review Date: Feb-24-2012
IETF LC End Date: Not known
IESG Telechat date: March-15-2012
Summary: This draft is ready as an Experimental.
Some minor comments and nits follow.
Major issues: 0
Minor issues: 3
Nits/editorial comments: 2
Minor:
1. Section 1 (S1), first paragraph:
s/session key would be used/session key is used/
2. S1, second paragraph: "...The AugPAKE protocol described in
this document is an augmented PAKE which also achieves measurable
efficiency over some previous works."
For sake of completeness, it may help to provide references to
the "previous works".
3. S1, second paragraph: "We believe the followings [SKI10]:" ---
s/followings/following/
but besides this, I am not sure what you are trying to say
here. Maybe a matter of expressing it in alternate English?
Nits:
1. S1, second paragraph: s/one and 1.17/1 and 1.17/
This makes it congruent with "2 and 2.17" that appears a
few lines above.
2. Email for author Kazukuni Kobara is missing.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-snell-atompub-tombstones-14
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-snell-atompub-tombstones-14
Reviewer: Vijay K. Gurbani
Review Date: Feb-08-2012
IETF LC End Date: Feb-21-2012
IESG Telechat date: Not known
Summary: This draft is ready as an Informational.
Major issues: 0
Minor issues: 0
Nits/editorial comments: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-softwire-gateway-init-ds-lite-06
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-softwire-gateway-init-ds-lite-06
Reviewer: Vijay K. Gurbani
Review Date: Jan-02-2012
IETF LC End Date: Jan-04-2012
IESG Telechat date: Jan-05-2012
Summary: This draft is ready as an Proposed Standard.
Major issues: 0
Minor issues: 0
Nits/editorial comments: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-gregorio-uritemplate-07
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-gregorio-uritemplate-07
Reviewer: Vijay K. Gurbani
Review Date: Jan-01-2012
IETF LC End Date: Not known
IESG Telechat date: Jan-05-2012
Summary: This draft is ready as an Proposed Standard.
Major issues: 0
Minor issues: 2
Nits/editorial comments: 0
Minor issue:
- S3.2.1, first paragraph: "A variable defined as an associative
array of (name, value) pairs is considered undefined if the
array contains zero members or if all member names in the array
have undefined values."
Here, do you mean "if all member names in the array have no values."?
That is, "undefined values" implies that values are present in the
template, but are not understood. On the other hand, "no values"
implies the absence of any values at all. In my reading of the
text, it appears that "no values" conveys more context than "undefined
values".
- S4, general comment: I am not sure where the template expansion is
done --- at the client (browser) or at the origin server (the draft
does not enunciate this, and if it does, I may have missed it). If
the expansion is done at the origin server, I suspect that one can
keep it a bit more busy by asking it to perform unnecessary
template expansion for a resource that may be accessed normally
even without template expansion. Is it worth documenting this at
all in the Security Considerations section? (Clearly, if the expansion
is done at the client, then it is the client incurring the expense
of expansion. Insofar as the client is malicious, it is best to
let it expend as much effort as necessary.)
Thanks,
- vijay
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-strrst-12
On 12/02/2011 03:25 PM, Michael Tuexen wrote:
the above is incorrect... It is not important which side establishes
the SCTP association. No matter how it was established, a uni-directional
stream is outgoing for one side, incoming for the other.
After the association has been established, you have n uni-directional
streams from A to B, and m uni-directional streams from B to A.
For the n streams, A is the outgoing side, B the incoming. For the m
streams, B is the outgoing side, A is the incoming side. No matter
if A is client, B is server, vice versa, or both were acting as peers.
Michael: OK, I suspect that the average reader of your draft
will have much more SCTP context than I do (my mind wants to view
SCTP through the TCP lens). So, I will defer to the modified
text you suggested in your earlier email [1].
I have no further comments.
[1] http://www.ietf.org/mail-archive/web/gen-art/current/msg06952.html
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
