Brian E Carpenter | 24 Oct 04:52 2014
Picon

Gen-ART Last Call review of draft-nottingham-safe-hint-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-nottingham-safe-hint-05.txt
Reviewer: Brian Carpenter
Review Date: 2014-10-24
IETF LC End Date: 2014-11-18
IESG Telechat date:

Summary:   Almost ready
--------

Comment:
--------

I have no technical comments. I have not been reading the IETF Last Call thread, but
my opinion fwiw is that this a figleaf that will provide no real protection.
Undesirable sites will simply ignore it. "Safe" sites don't need it.

Minor issues:
-------------

As the writeup says: "The IANA Considerations section is a bit sparse.
It should at least name the registry it's updating for convenience of the reader."
Martin Thomson | 24 Oct 04:35 2014
Picon

Gen-ART review of draft-ietf-manet-ibs-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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-manet-ibs-03
Reviewer: Martin Thomson
Review Date: 2014-10-23
IETF LC End Date: 2014-10-27
IESG Telechat date: (if known)

Summary: Ready with questions.

The language is quite clear and precise.  I did find that
comprehension required a non-trivial amount of digging into other
documents, but nothing was particularly hard to find.

This has a downref to 6507 (I see this in the shepherd writeup).

Questions:
The security considerations notes that the trusted authority has
access to private keys.  That would seem to defeat much of the benefit
of using asymmetric crypto here.  Why is this considered acceptable in
this context?  (I'd have thought it to be unacceptable in any context
when superior alternatives exist.)

The document mentions revocation, but does not seem to specify
anything.  If that is intentional, shouldn't the draft be more forward
(Continue reading)

Robert Sparks | 23 Oct 22:51 2014

Gen-art telechat review: draft-ietf-dart-dscp-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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-dart-dscp-08
Reviewer: Robert Sparks
Review Date: 23-Oct-14
IETF LC End Date: (past)
IESG Telechat date: 30-Oct-14

Summary: Ready for publication as an Informational RFC
A. Jean Mahoney | 23 Oct 22:39 2014

Assignments for the 2014-10-30 Telechat

Hi all,

The following reviewers have assignments:

Reviewer            LC end       Draft
------------------------------------------------------------------------------------

Alexey Melnikov        TR2014-10-24 draft-ietf-rtcweb-data-protocol-08

Ben Campbell           TR2014-09-11 draft-ietf-avtcore-srtp-aes-gcm-14 **
Ben Campbell           TR2014-10-24 draft-ietf-weirds-object-inventory-05 **

Brian Carpenter        TR2014-10-10 draft-ietf-softwire-map-dhcp-09 **
Brian Carpenter        TR2014-10-24 draft-ietf-weirds-rdap-query-15 **

Christer Holmberg      TR2014-10-24 draft-ietf-weirds-rdap-sec-09 **
Christer Holmberg      TR2014-10-10 draft-ietf-softwire-4rd-09 *

David Black            TR2014-10-10 draft-ietf-softwire-lw4over6-11 *
David Black            TR2014-10-27 draft-ietf-payload-g7110-03 **

Dan Romascanu          TR2014-10-10 draft-ietf-softwire-map-t-06 *
Dan Romascanu          TR2014-10-24 draft-ietf-weirds-json-response-10 **

Elwyn Davies           TR2014-09-25 
draft-ietf-dmm-best-practices-gap-analysis-08 *
Elwyn Davies           TR2014-10-27 
draft-ietf-mpls-mldp-in-band-wildcard-encoding-02

Francis Dupont         TR2014-10-10 draft-ietf-softwire-map-11 *
(Continue reading)

A. Jean Mahoney | 23 Oct 22:23 2014

A *new* batch of IETF LC reviews - 2014-10-23

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

Alexey Melnikov   2014-11-03   draft-ietf-mpls-pim-sm-over-mldp-02

Ben Campbell      2014-11-03   draft-ietf-mpls-deprecate-bgp-entropy-label-01

Brian Carpenter   2014-11-18   draft-nottingham-safe-hint-05

Christer Holmberg 2014-11-18   draft-kucherawy-rfc3777bis-01

Dan Romascanu     2014-11-19   draft-murdock-nato-nid-02

Tom Taylor        2014-10-31   draft-ietf-idr-error-handling-14 *

Vijay Gurbani     2014-11-03   draft-ietf-manet-nhdp-optimization-03

* Early review

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

(Continue reading)

Black, David | 22 Oct 17:44 2014

Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03

This is a combined Gen-ART and OPS-DIR review.  Boilerplate for both follows ...

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.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Document: draft-ietf-payload-g7110-03
Reviewer: David Black
Review Date: October 22, 2014
IETF LC End Date: October 27, 2014
IESG Telechat date: October 30, 2014

Summary: This draft is on the right track, but has open issues
 		described in the review.

Process note: This is the second draft that I've reviewed recently
that has been scheduled for an IESG telechat almost immediately
following the end of IETF Last Call.  The resulting overlap of
IETF LC with IESG Evaluation can result in significant last-minute
changes to the draft when issues are discovered during IETF LC.
(Continue reading)

Andy Newton | 22 Oct 02:00 2014
Picon

Re: [weirds] FW: Gen-ART Last Call review of draft-ietf-weirds-rdap-query-15

On 10/21/14, 6:49 AM, "Hollenbeck, Scott" <shollenbeck <at> verisign.com> wrote:

>>Major Issues:
>> -------------
>> 
>> Section 3.1.1 says:
>> 
>>   "The restricted
>>    rules to write a text representation of an IPv6 address [RFC5952]
>> are
>>    not mandatory."
>> 
>> Why not make 5952 at least a SHOULD? Personally, I would make it a
>> MUST. As 5952 itself states,
>> the ambiguity of the RFC 4291 format creates many problems. 5952 in any
>> case requires that
>> "all implementations must accept and be able to handle any legitimate
>> RFC 4291 format",
>> so making conformance with 5952 a SHOULD or MUST won't break anything.
>> 

Thanks for pointing out that sentence from 5952. Given that, though I
donĀ¹t see a MUST has helpful and in fact it might be confusing. My
recommendation is:

OLD

  Any valid IPv6 text address format [RFC4291] can be used, compressed or
not compressed.  The restricted
  rules to write a text representation of an IPv6 address [RFC5952
(Continue reading)

Ben Campbell | 21 Oct 00:55 2014

Gen-ART LC Review of draft-ietf-weirds-object-inventory-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-weirds-object-inventory-05
Reviewer: Ben Campbell
Review Date: 2014-10-20
IETF LC End Date: 2014-10-24

Summary: This draft is almost ready for publication as an informational RFC. However, there are quite a
number of editorial issues that probably should be considered first.

Major issues:

None

Minor issues:

-- section 4.5:

It may be worth mentioning that the data included instances where the same label was used for different
objects by different registries.

-- 5.5, first bullet:

(Continue reading)

Brian E Carpenter | 20 Oct 02:09 2014
Picon

Gen-ART Last Call review of draft-ietf-weirds-rdap-query-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-weirds-rdap-query-15.txt
Reviewer: Brian Carpenter
Review Date: 2014-10-20
IETF LC End Date: 2014-10-24
IESG Telechat date: 2014-10-30

Summary:   Almost ready
--------

Major Issues:
-------------

Section 3.1.1 says:

  "The restricted
   rules to write a text representation of an IPv6 address [RFC5952] are
   not mandatory."

Why not make 5952 at least a SHOULD? Personally, I would make it a MUST. As 5952 itself states,
the ambiguity of the RFC 4291 format creates many problems. 5952 in any case requires that
"all implementations must accept and be able to handle any legitimate RFC 4291 format",
so making conformance with 5952 a SHOULD or MUST won't break anything.

(Continue reading)

Adrian Farrel | 17 Oct 13:05 2014
Picon

Re: GenART review of draft-ietf-l2vpn-evpn-10

Hi Martin,

I firmly believe that all reviews are good reviews, and thank you for the time
you have put into this.

You'll understand, of course, the squawking noise made by the authors who
received your review the day after the IESG discussed your document on the
telechat. In fact, the last Discus cleared a short while ago, and I was just
about to click the friendly red button marked "Approved".  Including the
standard GenArt boilerplate about "last call comments" might be a tiny but
ironic :-)

But let's cut to the chase...

> I found the overview in Section 4 to be very...wooly.  

Hmmm.
I re-read and found it relatively to the point.
Sentences are quite short, and are all definitive.

> It launches
> straight into alphabet soup, 

True there are a lot of abbreviations.
But the terms are either well-known or described in Section 3.
For example, if a reader is unfamiliar with CE, PE, MPLS, IP, GRE, then I'm
afraid they will get nothing out of the document. Expanding the terms will not
help.

> but didn't manage to identify what it was
(Continue reading)

Martin Thomson | 17 Oct 01:57 2014
Picon

GenART review of draft-ietf-l2vpn-evpn-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-l2vpn-evpn-10
Reviewer: Martin Thomson
Review Date: 2014-10-16
IETF LC End Date: past
IESG Telechat date: 2014-10-16

Summary: I found no major issues here, but I'm not able to give this
proper time to do this justice.  I have some comments, but these need
to be considered in context of the time I've spent on this.  I'm
guessing a week might be adequate, but that's time I don't have for
GenART.

Issues:

I found the overview in Section 4 to be very...wooly.  It launches
straight into alphabet soup, but didn't manage to identify what it was
that the document was trying to achieve, vs. what already exists.  It
certainly raises questions: is this document going to address the
issue of how MAC learning is populated on devices in networks attached
to CE?  Is it going to deal with (MAC) learning on the PE and CE
equipment?  What information does the CE really need at the MAC layer
to do its job?  The information provided is definitely not enough to
(Continue reading)


Gmane