[Gen-art] Genart telechat review of draft-ietf-idr-bgp-prefix-sid-11

2018-02-01 Thread Peter Yee
Reviewer: Peter Yee
Review result: 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 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-ietf-idr-bgp-prefix-sid-11
Reviewer: Peter Yee
Review Date: 2018-02-01
IETF LC End Date: 2018-01-26
IESG Telechat date: 2018-02-08

Summary:  This update incorporates most of the changes I noted for the -10
draft and is ready for publication.

Major issues:

Minor issues:

Nits/editorial comments:

Okay, maybe spell my surname correctly. ;-)

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


Re: [Gen-art] Genart last call review of draft-ietf-mmusic-trickle-ice-sip-12

2018-02-01 Thread Thomas Stach

Dale,

first of all apologies for the delay in responding to your thorough review.

Thanks for your effort.

more inline


On 2018-01-24 04:45, Dale Worley wrote:

Reviewer: Dale Worley
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.

Document:  draft-ietf-mmusic-trickle-ice-sip-12
Reviewer:  Dale R. Worley
Review Date:  2018-01-23
IETF LC End Date:  2018-01-26
IESG Telechat date:  [unknown]

Summary:

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

This draft is technically quite good, and except for various nits,
quite well written.  But there are some significant technical issues
that need to be properly settled before the protocol is well-defined
with good advice on robust usage.  I don't think settling these issues
will be difficult.

** Global/major issues:

* The tokens "end-of-candidate" and "end-of-candidates" seem to be used
equivalently in this document, with the following number of uses:

  11 end-of-candidate
  19 end-of-candidates

Which is the correct form?

Hm, as the grammar says "end-of-candidates ", I'll change to the latter.

* The definition of application/trickle-ice-sdpfrag describes the use of
"a=charset" as an attribute, but the grammar of sdpfrag in section 9
does not permit that attribute.

The grammar allows for using extension attributes.
"a=charset" would be one of these, but might only be needed if non-ASCII 
characters are possibly introduced via some potential extension.


* Deployment considerations (section 11)

It might be worth mentioning here what happens if a middlebox deletes
Trickle ICE INFO requests because it does not understand them, but
does not delete "Supported: trickle-ice" headers.  It seems to me that
in order to be robust in this situation, a UA should provide a
globally routable address in the m= lines of the initial offer or
answer, or if Trickle ICE INFO requests fail, eventually amend the
addresses to be globally routable addresses.
There are so many ways how middle boxes can break any mechanism, that we 
can't do much to cover everything.
RFC 5245 has recommendations (e.g. relayed candidates will always work) 
on how to choose the default destination as provided in the m/c-line.
I don't think we need to repeat that reasoning here , and after all the 
user agent might not want to use such a globally routable address.


But the WG may have more knowledge about this situation.

* There are various locations where the language has usages that seem to
me to be excessively informal or prolix.  Cases I've noticed are:

2.  Terminology

It is assumed that the reader will be
familiar with the terminology from both documents.

Probably s/will be/is/.

OK


3.1.  Discovery issues

Such Offers and Answers can
only be handled meaningfully by agents that actually support
incremental candidate provisioning, which implies the need to confirm
such support before actually using it.

It's probably best to omit "actually" here and elsewhere.  There is
also a use of "right from the first Offer".  And in some places
"would" is used where it is not needed or could be replaced by "do";
"would" should (IMO) be restricted to situations that are
counter-factual.  There is also a use of "like for example" instead of
"for example".

I'll have pass through the document and look for these.


I expect the RFC Editor can give guidance on this subject.

** Detailed/editorial/nits:

A Session Initiation Protocol (SIP) usage for Trickle ICE
   draft-ietf-mmusic-trickle-ice-sip-12

The current practice is to capitalize "usage" in this situation.
(I expect the RFC Editor can give guidance on the current
capitalization style for RFCs.)

We switch to capitalized "Usage" as that  seems correct to me.


Abstract

This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP) and defines a new SIP Info Package.

Perhaps /a new SIP Info Package/a new SIP Info Package to support this
usage/.

Table of Contents

The capitalization of section titles seems to be inconsistent.

I'll have a pass through the section titles that are taken over into the ToC


1.  Introduction

It describes how ICE candidates
are to be exchanged incrementally with SIP INFO requests [RFC6086]

Probably s/exchanged incrementally with/exchanged incrementally
using/, as "with" can be read to mean that the SIP INFO requests are
one party which is exchanging.

ok


4.  Incremental Signaling of ICE candidates

The following sections provide further details on how Trickle ICE
Agents perform the initial Offers/Answers exchange (Section 4.1),
perform subsequent Offers/Answers exchanges (Section 4.2) and
establish the INVITE dialog usage (Section 

[Gen-art] Review Assignments

2018-02-01 Thread Jean Mahoney
Hi all,

The following reviewers have assignments:

For telechat 2018-02-08

Reviewer   Type  LC end Draft
Wassim Haddad  Last Call 2018-01-31 draft-ietf-rtgwg-ni-model-06
Matthew Miller Telechat  2018-02-07 
draft-ietf-tls-dnssec-chain-extension-06
Pete Resnick   Telechat  2018-02-07 
draft-ietf-netmod-yang-tree-diagrams-05
Dan Romascanu  Last Call 2018-02-05 draft-ietf-trill-ecn-support-04
Meral Shirazipour  Telechat  2017-12-04 draft-mm-wg-effect-encrypt-17 *
Peter Yee  Telechat  2018-01-26 draft-ietf-idr-bgp-prefix-sid-11 *

For telechat 2018-02-22

Reviewer   Type  LC end Draft
Brian CarpenterTelechat  None   draft-ietf-nvo3-hpvr2nve-cp-req-13
Elwyn Davies   Last Call 2018-02-14 draft-ietf-rtgwg-backoff-algo-07
Francis Dupont Last Call 2018-02-09 draft-ietf-bess-fat-pw-bgp-03
Roni Even  Last Call 2018-02-09 draft-ietf-bess-evpn-usage-07
Vijay Gurbani  Last Call 2018-02-09 draft-ietf-bess-dci-evpn-overlay-07
Joel Halpern   Last Call 2018-02-15 
draft-ietf-modern-problem-framework-03
Jouni Korhonen Telechat  None   draft-ietf-sacm-nea-swima-patnc-01

Last calls:

Reviewer   Type  LC end Draft
Linda Dunbar   Last Call 2018-02-14 
draft-ietf-mmusic-sdp-bundle-negotiation-48

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Fernando Gont
  Vijay Gurbani
  Wassim Haddad
  Joel Halpern
  Christer Holmberg
  Russ Housley
  Jouni Korhonen
  Paul Kyzivat
  Matthew Miller
  Pete Resnick

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
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: 

-- End LC Template --

-- Begin Telechat Template --
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:

-- End Telechat Template --


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


Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-prefix-sid-10

2018-02-01 Thread Acee Lindem (acee)
Hi Peter, 

On 2/1/18, 1:30 PM, "Peter Yee"  wrote:

Acee,
Thanks for the quick response. 

>>Change "extendibility" to "extensibility" throughout the document.

>No - see https://www.merriam-webster.com/dictionary/extendibility

Yeah, I looked over various dictionaries for that word.  Extensibility 
seemed to be more popular and in some dictionaries closer to what you meant, 
but either will work.

>>Page 4, Section 1, 4th paragraph, 1st sentence: delete the comma.

>I'm not sure exactly which comma you are referring to but I believe the 
punctuation is correct before "reducing".

That should have been Page 3.  Typo on my part.

Thanks - I'll remove that comma in the next revision (which there invariable 
will be). 

Acee 


I appreciate you addressing my comments (tardy as they were).

-Peter

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Wednesday, January 31, 2018 3:02 PM
To: Peter Yee; gen-art@ietf.org
Cc: i...@ietf.org; i...@ietf.org; draft-ietf-idr-bgp-prefix-sid@ietf.org
Subject: Re: Genart last call review of draft-ietf-idr-bgp-prefix-sid-10

Hi Peter, 

Thanks for the review, please see inline.

On 1/31/18, 2:44 PM, "Peter Yee"  wrote:

Reviewer: Peter Yee
Review result: Ready with Nits

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-idr-bgp-prefix-sid-10
Reviewer: Peter Yee
Review Date: 2018-01-31
IETF LC End Date: 2018-01-26
IESG Telechat date: 2018-02-08

Summary: This draft specifies an optional BGP attribute for use with 
Segment
Routing.  It's well written and reable, although I make no claims to 
being an
expert in this area.  The draft is ready for publication but has some 
nits that
should be fixed (really nothing major).

Major issues:

Minor issues:

Nits/editorial comments:

General:

Change "extendibility" to "extensibility" throughout the document.

No - see https://www.merriam-webster.com/dictionary/extendibility

Change "First Come, First Served" (with varying hyphenation) to simply
"first-come, first-served" in a few places.  Meaning making it lower 
case and
hyphenate consistently.

I've made this consistent with IANA terminology.


Specific.

Page 3, Section 1, 1st paragraph, 2nd sentence: change the colon to a 
comma.

Fixed.

Page 3, Section 1, 3rd paragraph, 1st sentence: append comma after the 
close
parenthesis, "label", and "Dataplane".

Fixed.

Page 4, Section 1, 4th paragraph, 1st sentence: delete the comma.

I'm not sure exactly which comma you are referring to but I believe the 
punctuation is correct before "reducing". 


Page 4, Section 1, 4th paragraph, last sentence: consider making 
"Segment"
lower case for consistency with previous usage.

Fixed.

Page 4, Section 2.1, 2nd indented paragraph, 2nd sentence: change "to 
use" to
"using".

Changed 

Page 7, Section 3.2, 1st paragraph, 2nd sentence: should the uses of 
"will be"
throughout the document be changed to "MUST"?

I've consistently used MUST throughout. 

Page 8, 2nd bullet item (Length): insert "a" before "multiple".

I've put it in parenthesis. 

Page 9, Section 4, 1st sentence: delete the comma.

Fixed.

Page 9, Section 4.1, 3rd paragraph, 1st sentence: delete "as".

Reworded.

Page 10, Section 4.2, 1st paragraph, 2nd sentence: delete the first 
"the".

Fixed.

Page 12, 1st paragraph, 2nd sentence: change "Similarily" to 
"Similarly".

Fixed.

Page 12, Section 7, 1st paragraph, 2nd sentence: insert "to" before the 
first
"the".

Fixed. 

Thanks,
Acee







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


Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-prefix-sid-10

2018-02-01 Thread Peter Yee
Acee,
Thanks for the quick response. 

>>Change "extendibility" to "extensibility" throughout the document.

>No - see https://www.merriam-webster.com/dictionary/extendibility

Yeah, I looked over various dictionaries for that word.  Extensibility seemed 
to be more popular and in some dictionaries closer to what you meant, but 
either will work.

>>Page 4, Section 1, 4th paragraph, 1st sentence: delete the comma.

>I'm not sure exactly which comma you are referring to but I believe the 
>punctuation is correct before "reducing".

That should have been Page 3.  Typo on my part.

I appreciate you addressing my comments (tardy as they were).

-Peter

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Wednesday, January 31, 2018 3:02 PM
To: Peter Yee; gen-art@ietf.org
Cc: i...@ietf.org; i...@ietf.org; draft-ietf-idr-bgp-prefix-sid@ietf.org
Subject: Re: Genart last call review of draft-ietf-idr-bgp-prefix-sid-10

Hi Peter, 

Thanks for the review, please see inline.

On 1/31/18, 2:44 PM, "Peter Yee"  wrote:

Reviewer: Peter Yee
Review result: Ready with Nits

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-idr-bgp-prefix-sid-10
Reviewer: Peter Yee
Review Date: 2018-01-31
IETF LC End Date: 2018-01-26
IESG Telechat date: 2018-02-08

Summary: This draft specifies an optional BGP attribute for use with Segment
Routing.  It's well written and reable, although I make no claims to being 
an
expert in this area.  The draft is ready for publication but has some nits 
that
should be fixed (really nothing major).

Major issues:

Minor issues:

Nits/editorial comments:

General:

Change "extendibility" to "extensibility" throughout the document.

No - see https://www.merriam-webster.com/dictionary/extendibility

Change "First Come, First Served" (with varying hyphenation) to simply
"first-come, first-served" in a few places.  Meaning making it lower case 
and
hyphenate consistently.

I've made this consistent with IANA terminology.


Specific.

Page 3, Section 1, 1st paragraph, 2nd sentence: change the colon to a comma.

Fixed.

Page 3, Section 1, 3rd paragraph, 1st sentence: append comma after the close
parenthesis, "label", and "Dataplane".

Fixed.

Page 4, Section 1, 4th paragraph, 1st sentence: delete the comma.

I'm not sure exactly which comma you are referring to but I believe the 
punctuation is correct before "reducing". 


Page 4, Section 1, 4th paragraph, last sentence: consider making "Segment"
lower case for consistency with previous usage.

Fixed.

Page 4, Section 2.1, 2nd indented paragraph, 2nd sentence: change "to use" 
to
"using".

Changed 

Page 7, Section 3.2, 1st paragraph, 2nd sentence: should the uses of "will 
be"
throughout the document be changed to "MUST"?

I've consistently used MUST throughout. 

Page 8, 2nd bullet item (Length): insert "a" before "multiple".

I've put it in parenthesis. 

Page 9, Section 4, 1st sentence: delete the comma.

Fixed.

Page 9, Section 4.1, 3rd paragraph, 1st sentence: delete "as".

Reworded.

Page 10, Section 4.2, 1st paragraph, 2nd sentence: delete the first "the".

Fixed.

Page 12, 1st paragraph, 2nd sentence: change "Similarily" to "Similarly".

Fixed.

Page 12, Section 7, 1st paragraph, 2nd sentence: insert "to" before the 
first
"the".

Fixed. 

Thanks,
Acee





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


Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11

2018-02-01 Thread Eliot Lear
I wrote:


On 29.01.18 23:07, Eliot Lear wrote:
>
> The line in question is as follows:
>
>   This includes,
>   but is not limited to, native and unmodified IPv4 and IPv6
>   connectivity, global reachability, and no additional limitation
>   that would materially impact their Internet use.
>
> How about:
>
> This includes,
>   but is not limited to, native and unmodified IPv4 and IPv6
>   connectivity, global reachability, and no additional limitation
>   that would materially impact their Internet use.

And what I meant to propose was this:

    It MUST be possible to provision
 Internet Access to the Facility and IETF Hotels that allows
 local attendees to utilize the Internet for all their IETF,
 business, and day to day needs; as well as sufficient
 bandwidth and access for remote attendees. This includes, but
is not
 limited to, native and unmodified IPv4 and IPv6 connectivity,
 global reachability, and no  additional limitation that would
 materially impact their Internet use.
 

Sorry for the confusion.


signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


Re: [Gen-art] Genart telechat review of draft-gutmann-scep-08

2018-02-01 Thread Christer Holmberg

Hi,

>>However, there are some issues (mostly editorial) that I would like the
>>authors to address.
>
> One comment on this, I didn't write the original text so I'll try and
> accommodate as much as possible, but in some cases I've had to guess at
>what
> the original authors intended.  Also, the explanations for several of the
> points raised in the questions is "it was like that when I got here".
>So in
> the following, when I respond with another question, it's because I'm
>not sure
> myself what should go in there, and I'm welcoming any suggestions...
>
> Another general point, because this has spent close to twenty years in
>draft
> status, it's been a de facto standard for most of that time so there are
> "standards-compliant" implementations that have been in use for more
>than a
> decade based on the draft.  Because of this, I've had to be very careful
>to
> avoid breaking things by introducing a MUST or MUST NOT after nearly two
> decades of something not being a MUST.  This is why, in some places,
>there's a
> SHOULD with strong hints rather than a MUST.
>
> The primary goal for this was to make it bits-on-the-wire compatible
>(apart
> from the unavoidable single DES + MD5 -> AES + SHA-2), and to minimise
> (ideally not to have any) breakage with deployed code.  So there are
>places
> where there are weasel-words ("we know you've been doing this for fifteen
> years but you probably shouldn't any more"), and others where I've
>retained
> text that I wouldn't have put in there if I'd been the one writting the
>doc.

Maybe some text about all that somewhere (e.g., in the Introduction
section, or in a dedicated ³History² section)?


>Q1:
>
>[Editing changes]
>
> I've had a go at changing this, but no matter what I do just ends up as
>the
> same wording shuffled around, I end up just moving bits from one
>location to
> another (it's already gone through a number of re-wordings across
>different
> drafts).  If there's a specific goal that you're aiming for with the
>changes I
> can try and hit that, but I just ended up saying more or less the same
>thing
> with different phrasing.

I just think it sounds weird to talk about a widely deployed protocol that
you are just about to publish.

But, maybe with some history (see previous comment) it would become more
clear.

---

>>Q2:
>>
>>Doesn¹t the "While implementers are encouraged toŠ" sentence belong to
>>the
>>Security Considerations?
>
>It's not a security consideration, unless I'm missing something it only
>discusses functionality and interoperability issues.

Ok.

---

>>Q3:
>>
>>The text says:
>>
>>   "A CA MAY enforce any arbitrary policies and apply them to certificate
>>   requests, and MAY reject any request."
>>
>>The "MAY reject any request" parts sounds unfinished. I assume it¹s
>>refers to
>>cases where the client don¹t support such arbitrary policies? If so, I
>>suggest
>>to explicitly say so.
>>
>>Currently it sounds like a generic CA-may-reject-any-request statement,
>>which
>>I assume is not what you intend to say :)
>
> That's exactly what it's meant to say: "You can ask for anything you
>want, but
> the CA isn't obligated to comply with your request".

Sure, but the text doesn¹t give any guidance on why it would reject the
request. Since the sentence is in the same sentence talking about policies
I assume the rejection would be if the policies are not fulfilled.

---

>>Q4:
>>
>>As the text talks about certificate distribution, is this really a
>>subsection
>>to section 2.1?
>
> "It was like that when I got here".  I can make it a non-subsection if
>it reads better that way.

I think it would be good. The text itself doesn¹t change, soŠ

---

>>Q5:
>>
>>The 4th paragraph contains a couple of SHOULDs. Is there a reason they
>>can¹t
>>be MUST?
>
>There are many ways to verify certs, those are just suggestions.  For
>example
>they may be hardcoded into the client (that's actually not uncommon in
>SCADA
>use), in which case there's nothing to verify.

Since you use ³SHOULD², it sounds more like just suggestions.

---

>>Q6:
>>
>>The 5th paragraph talks about how early versions of the draft used GET
>>messages for all communication.
>>
>>The text also says:
>>
>>³If the remote CA supports it, any of the CMS-encoded SCEP messages
>>SHOULD be
>>sent via HTTP POST instead of HTTP GET.²
>>
>>If the remove CA supports what? HTTP POST?
>
> Yes, fixed.
>
>>Why SHOULD, and not MUST?
>
> See the note about introducing breakage.
>
>>If the client understands to use POST if GET fails, why can¹t it use
>>POST to
>>begin with?
>
> It was meant to say (subtly) "if you're seeing these problems then
>perhaps
> it's time you updated your code".  I've changed the text to make this
>more
> explicit:
>
> The solution to this problem is to update the implementation to use HTTP
> POST instead.

Ok.

>>In general, what is the reason for having this text about early versions
>>of
>>the draft? Backward compatibility with CAs that will only support GET?
>
>Yes.  

Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11

2018-02-01 Thread Eliot Lear
Hi Alissa,


On 30.01.18 16:54, Alissa Cooper wrote:

>>> 'It is anticipated that
>>>   those roles will evolve.  The IASA MUST keep the
>>>   community informed in this regard, and MAY do so without updating
>>>   this memo.'
>> I don't think the MUST significantly changes the meaning, so I'm ambivalent 
>> about the change. Since this text was put in to address a comment in AD 
>> Evaluation, I'm inclined to hear from Alissa.
> Perhaps the concern could be addressed by saying “without first updating this 
> memo”? The point I raised is that this document shouldn’t gate the ability 
> for the roles to change, but certainly if they do change the document should 
> be updated (or obsoleted by a new document) to match the reality.
>

Editorially I don't think there is a full sentence that we want to add
to capture this.  The IASA is not responsible for this document, and I
don't think we want to make them responsible for it.  The community is
responsible.  Therefore, I suggest we run with Dan's text that simply
requires the IASA to keep the community informed of changes in a timely
fashion, and trust that the IASA will find the right means to do so.

Eliot





signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art