Re: [Gen-art] Gen-art LC review of draft-ietf-aqm-fq-codel-05

2016-03-10 Thread Elwyn Davies 

Hi, Dave/Toke.

Thanks in turn for your rapid responses.

It appears that much of this is straightforward.  I have added a few 
comments in line.  If you are able to produce an updated draft, I'll 
check through it again before the  end of Last call and the IESG meeting.


Cheers,
Elwyn

On 09/03/2016 21:04, Dave Taht wrote:

thx for such a comprehensive review! That is the most in-depth
critique we've had in a long time.

Some comments inline.

On Wed, Mar 9, 2016 at 9:12 AM, Elwyn Davies  wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-aqm-fq-codel-05.txt
Reviewer: Elwyn Davies
Review Date: 2016/03/06
IETF LC End Date: 2016/03/17
IESG Telechat date: (if known)  2016/03/17

Summary:
Almost ready.  There are a couple of minor issues that are barely above the
level of nits plus a fair bit of editorial work.

I notice that the draft is on the IESG agenda on the day that last call
ends.  If the authors wish to sort out the nits before the end of last call,
I will be happy to work with them on this.

Would be good.


Major issues:
None.

Minor issues:
Treatment of packets that don't fit into the hashing classification scheme:
The default FQ-CoDel hashing mechanism uses the protocol/addresses/ports
5-tuple, but there will be packets that don't fit this scheme (especially
ICMP).  There is no mention of what the classification would do with these
packets.

How about?

The default hashing algorithm SHOULD make a best effort attempt at
consistently decoding a flow for any given protocol. It MUST fall back
to a 3 tuple for anything not specifically recognized
(srcip,dstip,protocol), by default.
That seems sensible - but use consistent words for destination/source 
address and protocol number.


Did you see Brian Carpenter's note about issues with IPv6 when dealing 
with hardware supported systems?
Locating the protocol number (and port numbers) in IPv6 packets in 
packets with extension headers is a pain in the neck for fast hardware.


There isn't a lot that can be done about it immediately, but the problem 
ought to be mentioned.

...

Arp is essentially the only exception to this. (LLC or other obscure
wire protocols? IPX?) Due to the permutation in the hash ARP will
always end up in a single, consistent bucket (not necessarily 0) - it
is so small and so infrequent that normally fq_codel will attempt to
push it out first except in the case of a hash collision. If you are
in a situation where you are sending a ton of arp requests, and codel
is dropping them... you've got other problems.

Agreed.  Worth a few words perhaps.



I guess that one extra queue would probably suffice to hold any
such outliers, but it would be wise to say something about how the packets
from this/these queue(s) would be treated by the scheduler.  It might also
be useful to say something about treatment of outliers in other
classification schemes, if only to say that the scheme used needs to think
about any such outliers.

OK, but see above.


s6.2, last para:  The proposal to add flow related marking to encapsulated
packets needs to come with a very well exposed security and privacy health
warning.. [It occurs to me that it might be possible to confine these
markings to out of band notifications within the originating host which
would allow fq_codel or similar to Flow Queue the packets getting them into
a sensible order on the outgoing link.  Once the packets had been ordered in
this way, a subsequent box (maybe an ADSL modem or suchlike) linking a home
environment to the outside world could work purely on source address,
thereby interspersing the packets from different hosts onto the external
link but not needing to reorder the packets from each individual host.  Not
sure if this is a sensible idea but it looks like a way to avoid the privacy
issues.]

Obscuration happens a couple ways at the gateway - in linux the
hashing happens after the nat step in ipv4 typically, so the src ip is
the constant natted address, and we rely on the different ports,
protocol, and dest addr to distinguish the hash. In ipv6, it is end to
end, but in both cases the actual hash is permuted by a random number.

You can certainly see, from a packet capture off of a saturated link
that the traffic is being FQ'd. (and if ecn is enabled on the flows
and codel, when that is being applied) but I am not sure what this
actually "leaks" in terms of information.

Note that saturation does happen on tiny scales also - microbursts
will get broken up also on a nonsaturated link (example a typical TCP
dumps a whole IW10 via TSO on a wire at a gbit, then sent at 5mbit
over a cable modem)

I think, in trying to read what you wrote above, you are talking about

[Gen-art] review: draft-ietf-imapapnd-rfc2088bis-04

2016-03-10 Thread Joel M. Halpern 

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-imapapnd-rfc2088bis-04
IMAP4 non-synchronizing literals
Reviewer: Joel M. Halpern
Review Date: 10-March-2016
IETF LC End Date: 21-March-2016
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

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

Re: [Gen-art] Gen-Art LC review: draft-ietf-netmod-yang-metadata-04

2016-03-10 Thread Robert Sparks 



On 3/9/16 11:04 AM, Ladislav Lhotka wrote:

Hi Robert,

thanks for the review, I apologize for replying late, please see my responses 
inline:

Robert Sparks  writes:


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-netmod-yang-metadata-04
Reviewer: Robert Sparks
Review Date: 1Mar2016
IETF LC End Date: 9Mar2016
IESG Telechat date: not yet scheduled

Summary: Ready with nits

1) I might be missing something obvious, but the introduction has two
statements that don't seem aligned:

" Values of annotations are not limited to strings; any YANG built-in or
derived type may be used for them"
and
"annotations are scalar values and cannot be further structured".

These two statements are not in conflict: YANG data types (built-in or
derived) apply to scalar values.
I don't know what it means for a data type to apply to a value. Can you 
say that more simply?


I think this is just a language thing, and being precise in the text 
will get past it.


Are you saying all YANG data types (built-in or derived) have only 
scalar values?


If so, you could change the second point in the document to say
"Since annotations have only built-in or derived types, they can only 
have scalar values."


But then, placing the point under "This document deliberately adopts 
some restrictions" doesn't make sense, and I suggest restructuring the 
discussion to only call out the restrictions (which appears to be to not 
place annotations on lists or leaf-lists) below that sentence.






If I'm not missing something, that may be more of an open issue than a nit.

2) The shepherd writeup calls out the tension in figuring out whether to
make this an extension or a new built-in statement. Please consider
capturing the reasoning for the path you chose in the draft itself.

I will try, the main reason was that most people felt that introducing a
new built-in statement is too big a change for the upcoming maintenance
version of YANG (1.1) and YANG 2.0 is nowhere in sight.

Thanks, Lada












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

[Gen-art] Assignments for the 2016-03-17 Telechat

2016-03-10 Thread A. Jean Mahoney 

Hi all,

The following reviewers have assignments:

Reviewer  LC end   Draft
-
Brian Carpenter   03-15 draft-ietf-dprive-dns-over-tls-07 *

Christer Holmberg 03-15 draft-ietf-aqm-docsis-pie-02

Dan Romascanu 01-18 draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04 **
Dan Romascanu 03-30 draft-schoenw-opsawg-copspr-historic-03 **

Elwyn Davies  03-07 draft-wallace-est-alt-challenge-04 *
Elwyn Davies  03-17 draft-ietf-aqm-fq-codel-05 **

Fernando Gont 03-16 draft-ietf-cdni-redirection-17

Joel Halpern  03-09 draft-martin-urn-globus-02 **

Meral Shirazipour 02-26 draft-ietf-mmusic-proto-iana-registration-06 *

Pete Resnick  02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02
Pete Resnick  03-04 draft-ietf-p2psip-concepts-08

Peter Yee 03-08 draft-ietf-tictoc-ptp-mib-08 **

Ron Bonica03-09 draft-ietf-rtcweb-audio-10 **

Ralph Droms   03-09 draft-ietf-netmod-yang-json-08 *

Roni Even 02-09 draft-ietf-tsvwg-circuit-breaker-13 *

Russ Housley  03-14 draft-ietf-i2rs-architecture-13 **
Russ Housley  03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 **

Robert Sparks 03-09 draft-ietf-netmod-yang-metadata-04 *

Vijay Gurbani 03-14 draft-ietf-ccamp-otn-signal-type-subregistry-03

Wassim Haddad 03-15 draft-ietf-netext-pmipv6-flowmob-17

* Earlier draft reviewed
** Already reviewed


I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.

Note that reviews should ideally be posted to the gen-art mailing list
by COB on Tuesday:
http://wiki.tools.ietf.org/area/gen/trac/wiki/

Jean

---

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

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

[Gen-art] A *new* batch of IETF LC reviews - 2016-03-10

2016-03-10 Thread A. Jean Mahoney 

Hi all,

The following reviewers have assignments:

Reviewer  LC end  Draft
-
Francis Dupont2016-03-18  draft-ietf-avtext-sdes-hdr-ext-05

Joel Halpern  2016-03-21  draft-ietf-imapapnd-rfc2088bis-04

Jouni Korhonen2016-03-22
  draft-ietf-cdni-footprint-capabilities-semantics-12

Matt Miller   2016-03-23  draft-ietf-radext-bigger-packets-05

Meral Shirazipour 2016-03-24  draft-ietf-dime-drmp-04



I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The updated template is included below.

Thanks,

Jean

---

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

___
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-v6ops-host-addr-availability-05

2016-03-10 Thread Roni Even 
Hi,

I understand the recommendation and find it reasonable, Are members of the DHC 
WG aware of this usage?

Thanks

Roni

 

From: Lorenzo Colitti [mailto:lore...@google.com] 
Sent: Wednesday, March 09, 2016 4:59 PM
To: Roni Even
Cc: draft-ietf-v6ops-host-addr-availability@tools.ietf.org; IETF 
Discussion; gen-art@ietf.org
Subject: Re: Gen-ART LC review of draft-ietf-v6ops-host-addr-availability-05

 

Roni,

 

thanks for the review. To respond to your comment:

 

On Wed, Mar 9, 2016 at 7:06 AM, Roni Even  wrote:

Small question: In section 6 last bullet “While [RFC3633] assumes that the 
DHCPv6 client is a router, DHCPv6 PD itself does not require that the client 
forward IPv6 packets not addressed to itself, and thus does not require that 
the client be an IPv6 router as defined in [RFC2460].”

Is this a good practice to recommend?

Also I understand that in the here the recommendation is that all IPv6 packets 
will be addressed to the DHCPv6 client (not a router) and this is why he will 
not forward them.

 

The intent here is to say that while the DHCPv6 PD RFC uses the words 
"requesting router" to denote the DHCP client, is nothing in DHCPv6 PD itself 
that requires the PD client to be a router (where, in IPv6, the term "router" 
is defined in RFC2460).

 

So - even though the DHCPv6 PD RFC uses the term "requesting router", a host 
can use DHCPv6 PD to receive a prefix as well. The host can pick some addresses 
for that prefix for its own use, originate/terminate packets on those 
addresses, and not forward packets addressed to any of the other addresses in 
the prefix.

 

Regards,

Lorenzo

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

[Gen-art] Review of draft-sparks-genarea-mailarch-improvements-02

2016-03-10 Thread Ralph Droms 
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

>.

Document: draft-sparks-genarea-mailarch-improvements-02
Reviewer: Ralph Droms
Review Date: 2016-03-09
IETF LC End Date: 2016-02-18
IESG Telechat date: (if known): 2016-03-03

Summary: Ready for publication

Major issues: None

Minor issues: None

Nits/editorial comments: Reviewer's tardiness
I recognize I am late with this review; in fact, not just late, but I'm posting 
this review after it has been accepted for publication.  I was confused about 
the due date.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-ietf-netmod-yang-json-08

2016-03-10 Thread Ralph Droms 
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

>.

Document: draft-ietf-netmod-yang-json-08
Reviewer: Ralph Droms
Review Date: 2016-03-10
IETF LC End Date: 2016-03-10
IESG Telechat date: (if known)

Summary: This draft is ready for publication as a Standards Track RFC


Major issues: None

Minor issues: None

Nits/editorial comments: None


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art