Re: [Gen-art] [Pce] Review of draft-ietf-pce-stateful-pce-18

[Joel M. Halpern]

So it is intentional that this draft prohibits that behavior (PCE driven 
establishment)?


Yours,
Joel

On 2/16/17 11:35 PM, Dhruv Dhody wrote:

Hi Joel,

Regarding your comment -


Is the intention to prohibit the driving
of LSP creation from the PCE?


This capability is described in -
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 (document 
expired recently, authors should refresh it)

Thanks,
Dhruv


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Joel Halpern
Sent: 17 February 2017 09:08
To: gen-art@ietf.org
Cc: draft-ietf-pce-stateful-pce@ietf.org; p...@ietf.org; i...@ietf.org
Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18

Reviewer: Joel Halpern
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-pce-stateful-pce-??
Reviewer: Joel Halpern
Review Date: 2017-02-16
IETF LC End Date: 2017-02-28
IESG Telechat date: 2017-03-16

Summary:

Major issues:

Minor issues:
   At the end of section 5.4, the text talks about a PCE accepting status
updates even if the  stateful capability has not been negotiated.  Which is
fine.  But as written, the text seems to say that doing so means that the
PCE will be able to "build and maintain an up to date view of the state of
the PCC's LSPs".  However, if the capability has not been negotiated, I do
not see how the PCE can count on getting full and timely state reports.  Trying
to infer why a PCC is sending such a report in the absence of the agreement
seems problematic.

This comment may be a misunderstanding or mis-expectation on my part.
I would have expected one of the ways o using an active PCE is to have the
PCE decide (under suitable circumstances) that an LSP is needed between two
PCCs.  As far as I can tell, the text in section
5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP Update
Request (in a PCUpd message) for an LSP that has been delegated to it.  At
that point I thought that a PCC could delegate a block of unsetup LSPs to
the PCE.  But then looking at 5.8.2, the text states that for each delegation,
the PCC must request an initial path.  That seems to prohibit delegating a
block of LSPs for future updates.  Is the intention to prohibit the driving
of LSP creation from the PCE?

I have looked but I can not find the text explaining the significance
and use of the Symbolic path name.  It is mandated by the draft.  There seems
to be an implicit assumption taht it is needed by the PCE.  If the explanation
of how or why it is needed is not present, it should be.

Nits/editorial comments:
Should the text on the S bit in section 7.3 (the LSP Object
definition) note that it should be set to 0 on all messages sent by the PCE?
Should that also be stated for the R bit?  And the O bits?

  Section 9.2 seems very odd.  It states that the IETF "SHOULD" do some
additional work.  I understand why teh work is needed.  But this does not
seem to match the RFC 2119 meaning of SHOULD as it does not apply to eitehr
the implementor or the implementation.


___
Pce mailing list
p...@ietf.org
https://www.ietf.org/mailman/listinfo/pce


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

Re: [Gen-art] [Pce] Review of draft-ietf-pce-stateful-pce-18

[Dhruv Dhody]

Hi Joel, 

Regarding your comment - 

> Is the intention to prohibit the driving
> of LSP creation from the PCE?

This capability is described in - 
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 (document 
expired recently, authors should refresh it)

Thanks,
Dhruv 

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Joel Halpern
> Sent: 17 February 2017 09:08
> To: gen-art@ietf.org
> Cc: draft-ietf-pce-stateful-pce@ietf.org; p...@ietf.org; i...@ietf.org
> Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18
> 
> Reviewer: Joel Halpern
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-pce-stateful-pce-??
> Reviewer: Joel Halpern
> Review Date: 2017-02-16
> IETF LC End Date: 2017-02-28
> IESG Telechat date: 2017-03-16
> 
> Summary:
> 
> Major issues:
> 
> Minor issues:
>At the end of section 5.4, the text talks about a PCE accepting status
> updates even if the  stateful capability has not been negotiated.  Which is
> fine.  But as written, the text seems to say that doing so means that the
> PCE will be able to "build and maintain an up to date view of the state of
> the PCC's LSPs".  However, if the capability has not been negotiated, I do
> not see how the PCE can count on getting full and timely state reports.  
> Trying
> to infer why a PCC is sending such a report in the absence of the agreement
> seems problematic.
> 
> This comment may be a misunderstanding or mis-expectation on my part.
> I would have expected one of the ways o using an active PCE is to have the
> PCE decide (under suitable circumstances) that an LSP is needed between two
> PCCs.  As far as I can tell, the text in section
> 5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP Update
> Request (in a PCUpd message) for an LSP that has been delegated to it.  At
> that point I thought that a PCC could delegate a block of unsetup LSPs to
> the PCE.  But then looking at 5.8.2, the text states that for each delegation,
> the PCC must request an initial path.  That seems to prohibit delegating a
> block of LSPs for future updates.  Is the intention to prohibit the driving
> of LSP creation from the PCE?
> 
> I have looked but I can not find the text explaining the significance
> and use of the Symbolic path name.  It is mandated by the draft.  There seems
> to be an implicit assumption taht it is needed by the PCE.  If the explanation
> of how or why it is needed is not present, it should be.
> 
> Nits/editorial comments:
> Should the text on the S bit in section 7.3 (the LSP Object
> definition) note that it should be set to 0 on all messages sent by the PCE?
> Should that also be stated for the R bit?  And the O bits?
> 
>   Section 9.2 seems very odd.  It states that the IETF "SHOULD" do some
> additional work.  I understand why teh work is needed.  But this does not
> seem to match the RFC 2119 meaning of SHOULD as it does not apply to eitehr
> the implementor or the implementation.
> 
> 
> ___
> Pce mailing list
> p...@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

[Gen-art] Review of draft-ietf-pce-stateful-pce-18

[Joel Halpern]

Reviewer: Joel Halpern
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-pce-stateful-pce-??
Reviewer: Joel Halpern
Review Date: 2017-02-16
IETF LC End Date: 2017-02-28
IESG Telechat date: 2017-03-16

Summary:

Major issues:

Minor issues:
   At the end of section 5.4, the text talks about a PCE accepting
status updates even if the  stateful capability has not been
negotiated.  Which is fine.  But as written, the text seems to say
that doing so means that the PCE will be able to "build and maintain
an up to date view of the state of the PCC's LSPs".  However, if the
capability has not been negotiated, I do not see how the PCE can count
on getting full and timely state reports.  Trying to infer why a PCC
is sending such a report in the absence of the agreement seems
problematic.

This comment may be a misunderstanding or mis-expectation on my
part.  I would have expected one of the ways o using an active PCE is
to have the PCE decide (under suitable circumstances) that an LSP is
needed between two PCCs.  As far as I can tell, the text in section
5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP
Update Request (in a PCUpd message) for an LSP that has been delegated
to it.  At that point I thought that a PCC could delegate a block of
unsetup LSPs to the PCE.  But then looking at 5.8.2, the text states
that for each delegation, the PCC must request an initial path.  That
seems to prohibit delegating a block of LSPs for future updates.  Is
the intention to prohibit the driving of LSP creation from the PCE?

I have looked but I can not find the text explaining the
significance and use of the Symbolic path name.  It is mandated by the
draft.  There seems to be an implicit assumption taht it is needed by
the PCE.  If the explanation of how or why it is needed is not
present, it should be.

Nits/editorial comments: 
Should the text on the S bit in section 7.3 (the LSP Object
definition) note that it should be set to 0 on all messages sent by
the PCE?  Should that also be stated for the R bit?  And the O bits?

  Section 9.2 seems very odd.  It states that the IETF "SHOULD" do
some additional work.  I understand why teh work is needed.  But this
does not seem to match the RFC 2119 meaning of SHOULD as it does not
apply to eitehr the implementor or the implementation.


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

Re: [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

[tianxiang li]

Hi Jari,

Thank you for the support, and thanks to Roni as well as all the other kind
reviewers of this document.
We would update a new version of the document soon and cover the points
raised during last call.

Thanks and best regards,
Tianxiang

2017-02-16 20:04 GMT+08:00 Jari Arkko :

> Roni: thanks for your detailed review. I also appreciate
> the responses and changes by you Tianxiang. I have
> balloted no-objection for this document for today’s
> IESG telechat, and expect that the discussed changes
> will find themselves into a new document version at
> some point.
>
> Jari
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Joe Touch]

On 2/16/2017 1:29 PM, Stewart Bryant wrote:
>
>
> On 16/02/2017 18:49, Joe Touch wrote:
>>
>> On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>>>
>>> On 14/02/2017 23:00, Templin, Fred L wrote:
 Unless there is operational assurance of
 some size X>1280, however, tunnels have to use fragmentation to
 guarantee that - at a minimum - packets up to 1280 will get through.
>>> In that case there really needs to be a note about MPLS.
>> IMO, this doc shouldn't be discussing tunneling as any different from
>> any other link.
>>
>>> You can fragment into an IP tunnel, but not an MPLS tunnel, because
>>> you cannot fragment the payload as you can in IPv4 and you cannot
>>> fragment MPLS.
>> There's no such thing as an "MPLS tunnel";
>
> In the MPLS world an "MPLS tunnel" is a common name for an MPLS LSP that
> is used to carry some payload such as IP.

MPLS just adds the label tags; there's no length field.  It's only a
tunnel when it goes over some other encapsulation layer, e.g., IP or
Ethernet.

>
>> at best, it's "MPLS over X",
>> e.g., MPLS over ethernet. MPLS doesn't indicate a message length so
>> while it can't support fragmentation it would never need it either. It
>> would be the next layer down (e.g., Ethernet, ATM, etc.) that might have
>> needed fragmentation.  If that can't be supported, then the addition of
>> MPLS would just reduce the effective MTU of the MPLS-over-X link.
>
> It was of course IPv6 over MPLS that concerned me.

IPv6 over MPLS isn't yet a tunnel. It would be IPv6 over MPLS over IPv6,
presumably (IPv6 over IPv4 isn't guaranteed to work because IPv4 EMTU_R
is only 576, and for an IPv6 tunnel it would be required to be at least
1280+encaps).

An IPv6 packet can traverse an IPv6 over MPLS over Ethernet tunnel (with
a 1500B payload) as long as the MPLS headers are smaller than 1500-1280
bytes.

An IPv6 packet can traverse an IPv6 over MPLS over IPv6 tunnel as long
as the MPLS + added IPv6 headers are smaller than 1500-1280 bytes.
However, if the arriving (transit) packet is larger than
1280-MPLS-IPv6ecaps, the MPLS tunnel ingress would need to do source
fragmentation inside the tunnel (with the egress doing reassembly).

Again, all these cases are discussed in draft-ietf-intarea-tunnels but
none have relevance IMO to this doc.

Joe

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Joe Touch]

On 2/16/2017 11:59 AM, Brian E Carpenter wrote:
> On 17/02/2017 04:59, Stewart Bryant wrote:
>>
>> On 14/02/2017 23:00, Templin, Fred L wrote:
>>> Unless there is operational assurance of
>>> some size X>1280, however, tunnels have to use fragmentation to
>>> guarantee that - at a minimum - packets up to 1280 will get through.
>> In that case there really needs to be a note about MPLS.
>>
>> You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
>> cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.
> I'm confused. A tunnel end point that accepts IPv6 packets MUST accept packets
> of 1280 bytes (or shorter) and MUST emit them. How it gets them through the
> tunnel is irrelevant - if it's an ATM tunnel it has to chop them into 48 byte
> fragments and re-assemble them at the other end - if it's an avian carrier 
> tunnel
> it might have to use several pigeons per packet*. None of this matters to the 
> IPv6
> nodes concerned; the physical MTU of the tunnel technology is irrelevant 
> except
> to the tunnel end points.
There are too many systems that try to optimize the link MTU to
represent the size of the payload of the link source, rather than the
reassembly limit of the link receiver.

It's trying to make PMTUD work multiple layers down rather than stopping
at the IP layer (which I think is where it should stop).

Joe

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Brian E Carpenter]

On 17/02/2017 04:59, Stewart Bryant wrote:
> 
> 
> On 14/02/2017 23:00, Templin, Fred L wrote:
>> Unless there is operational assurance of
>> some size X>1280, however, tunnels have to use fragmentation to
>> guarantee that - at a minimum - packets up to 1280 will get through.
> 
> In that case there really needs to be a note about MPLS.
> 
> You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
> cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.

I'm confused. A tunnel end point that accepts IPv6 packets MUST accept packets
of 1280 bytes (or shorter) and MUST emit them. How it gets them through the
tunnel is irrelevant - if it's an ATM tunnel it has to chop them into 48 byte
fragments and re-assemble them at the other end - if it's an avian carrier 
tunnel
it might have to use several pigeons per packet*. None of this matters to the 
IPv6
nodes concerned; the physical MTU of the tunnel technology is irrelevant except
to the tunnel end points.

   Brian

*In RFC 6214, we didn't consider this, but we should have.

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Joe Touch]

On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>
>
> On 14/02/2017 23:00, Templin, Fred L wrote:
>> Unless there is operational assurance of
>> some size X>1280, however, tunnels have to use fragmentation to
>> guarantee that - at a minimum - packets up to 1280 will get through.
>
> In that case there really needs to be a note about MPLS.

IMO, this doc shouldn't be discussing tunneling as any different from
any other link.

> You can fragment into an IP tunnel, but not an MPLS tunnel, because
> you cannot fragment the payload as you can in IPv4 and you cannot
> fragment MPLS.

There's no such thing as an "MPLS tunnel"; at best, it's "MPLS over X",
e.g., MPLS over ethernet. MPLS doesn't indicate a message length so
while it can't support fragmentation it would never need it either. It
would be the next layer down (e.g., Ethernet, ATM, etc.) that might have
needed fragmentation.  If that can't be supported, then the addition of
MPLS would just reduce the effective MTU of the MPLS-over-X link.

Joe

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

Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Stewart Bryant]

On 14/02/2017 23:00, Templin, Fred L wrote:

Unless there is operational assurance of
some size X>1280, however, tunnels have to use fragmentation to
guarantee that - at a minimum - packets up to 1280 will get through.


In that case there really needs to be a note about MPLS.

You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.


Stewart

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

Re: [Gen-art] Gen-Art Last Call review of draft-ietf-sidr-delta-protocol-06

[Jari Arkko]

Thanks!

On 16 Feb 2017, at 17:29, Tim Bruijnzeels  wrote:

> Hi Jari, all,
> 
> Comment noted and should make it to an update when we process the other 
> comments received!
> 
> Tim
> 
> 
>> On 16 Feb 2017, at 12:58, Jari Arkko  wrote:
>> 
>> Thanks for your review, Orit!
>> 
>> (Authors, did you note the comment?)
>> 
>> Jari
>> 
> 



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

Re: [Gen-art] Gen-Art Last Call review of draft-ietf-sidr-delta-protocol-06

[Tim Bruijnzeels]

Hi Jari, all,

Comment noted and should make it to an update when we process the other 
comments received!

Tim


> On 16 Feb 2017, at 12:58, Jari Arkko  wrote:
> 
> Thanks for your review, Orit!
> 
> (Authors, did you note the comment?)
> 
> Jari
> 

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

Re: [Gen-art] review of draft-ietf-bmwg-ipv6-nd-04.txt

[Cerveny, Bill]

Hi Jari

I’ll review the comments and respond to them.

Thanks,

Bill Cerveny

On 2/16/17, 7:47 AM, "Jari Arkko"  wrote:

Thanks for the detailed review, Francis!

Authors — did you make a note of the comments? Did not see a response…

Jari

On 24 Jan 2017, at 18:33, Francis Dupont  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-bmwg-ipv6-nd-04.txt
> Reviewer: Francis Dupont
> Review Date: 20170116
> IETF LC End Date: 20170123
> IESG Telechat date: unknown
> 
> Summary: Ready with nits
> 
> Major issues: none
> 
> Minor issues: the title (and the Abstract) is a bit misleading: it is
> not the benchmarking of the ND protocol which has ~12 different
> functions but the benchmarking of a particular function on a router.
> Now it is the critical one so my concern is more the document is
> limited to only this one...
> 
> Nits/editorial comments:
> - ToC page 2 and 7 page 12: Acknowledgements -> Acknowledgments
> 
> - 1 page 2: the limit to a router explains why the verb send is
>  replaced by forward... and why there is nothing about redirection
> 
> - 1 page 2: determine the IPv6 next-hop's link-layer address
>  -> determine the outgoing interface and the IPv6 next-hop's
>   link-layer address
> 
> - 2.2.1 page 5: et cetera -> etc
> 
> - 3.1.2 page 9 (twice) and 3.2.2 page 10; recieved -> received
> 
> - 3.1.2 page 9: IMHO you should define the "initial" term (for final
>  the meaning is obvious)
> 
> - 3.2.1 page 10: (i.e.,IPv6 -> (i.e., IPv6
> 
> - 3.2.2 page 10: in "packets-received will either be
>   equal to zero or packets-received." the last received -> sent.
> 
> Regards
> 
> francis.dup...@fdupont.fr
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



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

Re: [Gen-art] Review of draft-ietf-bmwg-virtual-net-04

[MORTON, ALFRED C (AL)]

Hi Joel,
Thanks for your review, please see below.
Al

> -Original Message-
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: Sunday, February 05, 2017 4:44 PM
> To: gen-art@ietf.org
> Cc: draft-ietf-bmwg-virtual-net@ietf.org; i...@ietf.org;
> b...@ietf.org
> Subject: Review of draft-ietf-bmwg-virtual-net-04
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 
...
> Document: draft-ietf-bmwg-virtual-net-??
> Reviewer: Joel Halpern
> Review Date: 2017-02-05
> IETF LC End Date: 2017-02-15
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as an Informational
> RFC.
> 
> Major issues:
> 
> Minor issues:
> The second figure in section 4.4 talks about the use of multiple
> 3x3 tables, but appears to show the use of multiple 4x4 tables.  This
> reader found himself confused.

[ACM] 
The "3x3 matrix" refers to the cells of the table where 
user entries appear. The Header Row and Header Column
aren't included in the 3x3 matrix, but they do make the 
table appear as 4x4, as in the first figure of sec4.4. 
The Headings disappear in the second figure 
(due to size constraints), but the tables include
the 3x3 matrix as before.


> 
> Nits/editorial comments:
> 

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

Re: [Gen-art] review of draft-ietf-bmwg-ipv6-nd-04.txt

[Jari Arkko]

Thanks for the detailed review, Francis!

Authors — did you make a note of the comments? Did not see a response…

Jari

On 24 Jan 2017, at 18:33, Francis Dupont  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-bmwg-ipv6-nd-04.txt
> Reviewer: Francis Dupont
> Review Date: 20170116
> IETF LC End Date: 20170123
> IESG Telechat date: unknown
> 
> Summary: Ready with nits
> 
> Major issues: none
> 
> Minor issues: the title (and the Abstract) is a bit misleading: it is
> not the benchmarking of the ND protocol which has ~12 different
> functions but the benchmarking of a particular function on a router.
> Now it is the critical one so my concern is more the document is
> limited to only this one...
> 
> Nits/editorial comments:
> - ToC page 2 and 7 page 12: Acknowledgements -> Acknowledgments
> 
> - 1 page 2: the limit to a router explains why the verb send is
>  replaced by forward... and why there is nothing about redirection
> 
> - 1 page 2: determine the IPv6 next-hop's link-layer address
>  -> determine the outgoing interface and the IPv6 next-hop's
>   link-layer address
> 
> - 2.2.1 page 5: et cetera -> etc
> 
> - 3.1.2 page 9 (twice) and 3.2.2 page 10; recieved -> received
> 
> - 3.1.2 page 9: IMHO you should define the "initial" term (for final
>  the meaning is obvious)
> 
> - 3.2.1 page 10: (i.e.,IPv6 -> (i.e., IPv6
> 
> - 3.2.2 page 10: in "packets-received will either be
>   equal to zero or packets-received." the last received -> sent.
> 
> Regards
> 
> francis.dup...@fdupont.fr
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



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

Re: [Gen-art] Review of draft-ietf-mmusic-sctp-sdp-23

[Jari Arkko]

Brian, Christer: thanks.

Jari




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

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-tp-linear-protection-mib-11

[Jari Arkko]

All: thanks for the review and discussion. I plan to vote “no-objection” for 
this document in tonight’s IESG telechat.

Jari



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

Re: [Gen-art] Gen-ART review of draft-ietf-dnsop-edns-key-tag-04

[Jari Arkko]

Thanks!

On 01 Feb 2017, at 23:18, Christer Holmberg  
wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> 
> 
> Document:   draft-ietf-dnsop-edns-key-tag-04.txt
> Reviewer: Christer Holmberg
> Review Date:   1 February 2017
> IETF LC End Date:   14 February 2017
> IETF Telechat Date:16 February 2017
> 
> Summary: My comments on a previous version (-03) of the document have been 
> addressed, and the document is now ready for publication.
> Major Issues: None
> 
> Minor Issues: None
> 
> Editorial Issues: None
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



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

Re: [Gen-art] Review of draft-ietf-ccamp-flexible-grid-ospf-ext-08

[Jari Arkko]

Thanks for your (re)-review Pete

Jari



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

Re: [Gen-art] Review of draft-ietf-dmm-4283mnids-04

[Jari Arkko]

Dale:

Many thanks for this review, which indeed was exceptionally useful. (“Super” as 
Charlie put it.)

I have placed a no-objection position for this document for tonight’s IESG 
telechat. But I think your discussion on the details of changes inspired by 
Dale’s review probably needs to continue, and I also see that there are other 
points made by my AD colleagues — that is another discussion that needs to 
finish.

Jari



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

Re: [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

[Jari Arkko]

Roni: thanks for your detailed review. I also appreciate
the responses and changes by you Tianxiang. I have
balloted no-objection for this document for today’s
IESG telechat, and expect that the discussed changes
will find themselves into a new document version at
some point.

Jari



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

Re: [Gen-art] Gen-Art Last Call review of draft-ietf-sidr-delta-protocol-06

[Jari Arkko]

Thanks for your review, Orit!

(Authors, did you note the comment?)

Jari



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

Re: [Gen-art] Review of draft-ietf-oauth-jwsreq-11

[Jari Arkko]

Many thanks for your review, Joel.

I have balloted no-objection for this document on today’s IESG telechat.

Jari

On 03 Feb 2017, at 01:03, Joel Halpern  wrote:

> Reviewer: Joel Halpern
> Review result: Not Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-oauth-jwsreq-??
> Reviewer: Joel Halpern
> Review Date: 2017-02-02
> IETF LC End Date: 2017-02-13
> IESG Telechat date: 2017-02-16
> 
> Summary: This document is ready for publication as a Proposed
> Standard
> 
> Major issues: N/A
> 
> Minor issues:
>Why is the example if section 4 (and others later on) described
> as
> "non-normative"?  Is it incomplete?  incorrect?  An example is, by
> definition, not a full specification.  The language seems designed to
> reduce the value of the example.  I would recommend removing all the
> "non-normative" notes from the examples.  They are clearly stated to
> be examples.
> 
> Nits/editorial comments:
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



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

Re: [Gen-art] Review of draft-ietf-6tisch-minimal-19

[Jari Arkko]

On 05 Feb 2017, at 19:43, Suresh Krishnan  wrote:

> Thanks a lot for your review Brian.

+1

Jari



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