Re: [Gen-art] [bmwg] Genart telechat review of draft-ietf-bmwg-sdn-controller-benchmark-meth-08

[Alissa Cooper]

Stewart, thanks for your reviews. Bhuvan, thanks for addressing Stewart’s 
comments. I entered a No Objection ballot.

Alissa

> On Apr 17, 2018, at 2:04 AM, bhuvaneswaran.vengainat...@veryxtech.com wrote:
> 
> Hi Stewart ,
> 
> Thank you reviewing the changes in the revised draft. We apologize for missed 
> out some of your comments. We will address them as mentioned below in the 
> newer draft version.
> 
> 1. Regarding your #1 comment, we will add a note to mention that 'OpenFlow 
> protocol is used as an example to illustrate the methodologies defined in 
> this document'. Hope this works
> 2. We will clarify about the Test Traffic Generators (TP1/2) connectivity in 
> the setup. We will update such that 'TP1 SHOULD be connected to Network 
> Device 1 and TP2 SHOULD be connected to Network Device n'.
> 
> Best regards,
> Bhuvan
> 
> On Mon, Apr 16, 2018 at 06:18 PM, Stewart Bryant  
> wrote:
> Reviewer: Stewart Bryant
> 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 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-bmwg-sdn-controller-benchmark-meth-08
> Reviewer: Stewart Bryant
> Review Date: 2018-04-16
> IETF LC End Date: 2018-02-02
> IESG Telechat date: 2018-04-19
> 
> Summary:
> 
> This is a well written comprehensive test set for SDN controllers. Two minor
> points remain from my previous review that I would draft to the attention of
> the responsible AD.
> 
> Major issues: None
> 
> Minor issues:
> 
> I found the large amount of text on Openflow that appears out of the blue in
> the appendix somewhat strange since the test suit is controller protocol
> agnostic. I understand that this is included by way of illustrative example. 
> It
> might be useful to the reader to make a statement to this effect.
> 
> Nits/editorial comments:
> 
> The test traffic
> generators TP1 and TP2 SHOULD be connected to the first and the last
> leaf Network Device.
> 
> SB> I am sure I know what does first and last mean, but the meaning should be
> called out.
> 
> ___
> bmwg mailing list
> b...@ietf.org 
> https://www.ietf.org/mailman/listinfo/bmwg 
> DISCLAIMER: Privileged and/or 
> Confidential information may be contained in this message. If you are not the 
> addressee of this message, you may not copy, use or deliver this message to 
> anyone. In such event,you should destroy the message and kindly notify the 
> sender by reply e-mail. It is understood that opinions or conclusions that do 
> not relate to the official business of the company are neither given nor 
> endorsed by the company.
> ___
> 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] Genart telechat review of draft-ietf-stir-rph-03

[Alissa Cooper]

Brian, thanks for your review. I have entered a No Objection ballot.

Alissa

> On Apr 2, 2018, at 10:36 PM, Brian Carpenter  
> wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready
> 
> Gen-ART *Last Call* review of draft-ietf-stir-rph-03
> 
> 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-stir-rph-03.txt
> Reviewer: Brian Carpenter
> Review Date: 2018-04-03
> IETF LC End Date: 2018-04-06
> IESG Telechat date: 2018-04-19
> 
> Summary: Ready
> 
> 
> Comments:
> -
> This is a well written draft and I have no technical comments.
> 
> The draft says it extends RFC8225. Some people would say that needs
> an Updates: 8225 header.
> 
> Nits:
> -
> 
> 8.1.  Normative References
> 
>   [I-D.ietf-stir-passport]
>  Wendt, C. and J. Peterson, "Personal Assertion Token
>  (PASSporT)", February 2017.
> 
> Is now RFC8225.
> 
>   [I-D.ietf-stir-rfc4474bis]
>  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
>  "Authenticated Identity Management in the Session
>  Initiation Protocol (SIP)", February 2017.
> 
> Is now RFC8224.
> 
> 
> ___
> 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] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

[Alissa Cooper]

Dale, thanks for your reviews. Marc, thanks for your response. I have entered a 
No Objection ballot.

Alissa

> On Apr 16, 2018, at 5:49 PM, Marc Petit-Huguenin  
> wrote:
> 
> Thanks again for the review.  Comments inline.
> 
> On 03/30/2018 04:45 AM, Dale Worley wrote:
>> Reviewer: Dale Worley
>> 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 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-tram-stunbis-16
>> Reviewer:  Dale R. Worley
>> Review Date:  2018-03-29
>> IETF LC End Date:  2018-02-20
>> IESG Telechat date:  2018-04-19
>> 
>> Summary:
>> 
>>   This draft is basically ready for publication, but has nits
>>   that should be fixed before publication.
>> 
>> The only interesting item concerns section 17.1, where the assignment
>> of meanings to bits in the "security feature set" value is different
>> from the assignment in -16.  This is either non-upward-compatible with
>> -16, or there is an error in either -16 or -17.
>> 
>> --
>> 
>> There is an issue that shows up in several places:  The NAT may
>> forward the request using an IP family that is different from the IP
>> family that it received the request using.  This means that the
>> "source IP family of the request" may depend on whether one is
>> speaking of the client or the server.  The draft is cognizant of this,
>> and mentions its consequences in sections 6.3.3 and 12.  But this also
>> has consequences for ALTERNATE-SERVER:  Section 14.15 says "The IP
>> address family MUST be identical to that of the source IP address of
>> the request." even though that family might not be usable by the
>> client.  The draft doesn't seem to explicitly say that this comes from
>> address-switching by the NAT.  It would help if there was a
>> higher-level discussion of this matter, pointing to the various
>> consequences.
> 
> I still do not have text about that but, as this is blocking this response 
> since 2 weeks now, I am releasing it as is and will come back to that after I 
> process the other reviews that accumulated during my time traveling around 
> Europe.
> 
>> 
>> 3.  Terminology
>> 
>> This section needs to be updated to reference RFC 8174, including
>> updating the paragraph (especially the final two lines) to read as
>> specified in RFC 8174:
>> 
>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>>  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>>  "MAY", and "OPTIONAL" in this document are to be interpreted as
>>  described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>>  appear in all capitals, as shown here.
> 
> Updated.
> 
>> 
>> 6.2.2.  Sending over TCP or TLS-over-TCP
>> 
>>   o  if multiplexing other application protocols over that port, has
>>  finished using that other protocol, and
>> 
>> The two clauses don't match in grammatical number.  This should be
>> either
>> 
>>   o  if multiplexing other application protocols over that port, has
>>  finished using those other protocols, and
>> 
>> or
>> 
>>   o  if multiplexing another application protocol over that port, has
>>  finished using that other protocol, and
> 
> Updated using the former.
> 
>> 
>> 9.2.4.  Receiving a Request
>> 
>>  *  If the request contains neither PASSWORD-ALGORITHMS nor
>> PASSWORD- ALGORITHM, then the request is processed as though
>> PASSWORD- ALGORITHM were MD5 (Note that if the original
>> PASSWORD-ALGORITHMS attribute did not contain MD5, this will
>> result in a 400 Bad Request in a later step below).
>> 
>> There are two places where s/PASSWORD- ALGORITHM/PASSWORD-ALGORITHM/.
> 
> Already fixed following a previous review.
> 
>> 
>> 14.3.  USERNAME
>> 
>>   The value of USERNAME is a variable-length value containing the
>>   authentication username.  It MUST contain a UTF-8 [RFC3629] encoded
>>   sequence of less than 509 bytes, and MUST have been processed using
>>   the OpaqueString profile [RFC8265].  A compliant implementation MUST
>>   be able to parse UTF-8 encoded sequence of less than 763.
>> 
>> The final "763" is grammatically incorrect.  I think you intend
>> s/763/763 bytes/, to parallel other items.
> 
> Fixed.
> 
>> 
>> 14.4.  USERHASH
>> 
>>   userhash = SHA-256(Opaque(username) ":" Opaque(realm))
>> 
>> I believe that this should be
>> 
>>   userhash = SHA-256(OpaqueString(username) ":" OpaqueString(realm))
> 
> Fixed.
> 
>> 
>> 14.5.  MESSAGE-INTEGRITY
>> 
>>   Petit-Huguenin, et al.  Expires September 6, 2018 [Page 40]
>> 
>>   Internet-Draft Session Traversal 

Re: [Gen-art] Genart last call review of draft-ietf-mmusic-rid-14

[Alissa Cooper]

Robert, thanks for your review. I have entered a No Objection ballot and 
flagged your comments to the authors.

Alissa

> On Feb 27, 2018, at 3:54 PM, Robert Sparks  wrote:
> 
> Reviewer: Robert Sparks
> 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-mmusic-rid-14
> Reviewer: Robert Sparks
> Review Date: 2018-02-27
> IETF LC End Date: 2018-03-30
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready with nits
> 
> Nits:
> 
> I could see implementor disagreement around what's allowed when modifying a
> session driven by the statement in the introduction that "They do not relax 
> any
> existing descriptions." (where "They" here are the restrictions communicated
> with this attribute). Please look for a way to make it clear that an updating
> offer-answer round _can_ result in fewer restrictions than the original round
> did, just not fewer restrictions than the description places on the media if
> the "rid" extension is not present.
> 
> (Micronit): I don't think the "To be clear" in the first paragraph on page 5
> helps. I also worry that "it" may not have a clear meaning in "Such
> implementations must send it" later in that paragraph.
> 
> At the description of max-bpp on page 7, the last sentence is awkward. Do you
> perhaps mean "These values MUST NOT be encoded with more than four digits to
> the right of the decimal point."?
> 
> In the second paragraph of section 6, "its own unique 5-tuple" is arcane if 
> the
> reader hasn't read the rest of the rtcweb work. Could you provide a 
> description
> or a pointer to a description here?
> 
> At section 6.3, where you say 'For each "a=rid" line:', should you say 'For
> each "a=rid" line that has not been discarded by the requirements in section
> 6.2:'?
> 
> I found "a non-empty union" to be a confusing description of the condition you
> are trying to convey in section 8. (A union of two sets, at least one of which
> is not empty is going to be non-empty). I'm not sure intersection is the right
> word here either. Perhaps you could find a different way to characterize the
> condition?
> 
> The BNF for rid-id allows rid-ids like "This-is_my-favorite" or
> "Gm-Cqzkj4VHVD". But all the examples use single digits for rid-ids. I see the
> statement that "the actual identifiers used for RIDs are expected to be
> opaque". I strongly encourage putting some opaque ones in the examples.
> 
> Consider reminding people that ABNF quoted strings are case-insensitive, and
> that the grammar as written will allow things like "MaX-WiDtH" and "rECv". If
> that's not what you want, consider bringing in RFC7405. 
> 
> 
> ___
> 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-curdle-pkix-06.txt

[Alissa Cooper]

Francis, thanks for the review. I have entered a No Objection ballot.

Alissa

> On Oct 9, 2017, at 9:13 AM, 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-curdle-pkix-06.txt
> Reviewer: Francis Dupont
> Review Date: 20171002
> IETF LC End Date: 20171009
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: 
> - ToC page 2 and 11 page 14: Acknowledgements -> Acknowledgments
> 
> - 2 page 3: there is now a RFC updating 2119 to solve the lower case
>  keyword issue. I don't know if there is a policy about this, e.g.,
>  improving the standard 2119 reference text. I'll ask to the gen-art.
> 
> - 3 page 4: "a small number of implementations may still require"
>  for instance of (not ambiguous) use of a 2119 keyword in lower case
>  (so now a priori in its English language meaning).
> 
> Regards
> 
> francis.dup...@fdupont.fr
> 
> PS: BTW I know this draft before being assigned as its gen-art reviewer,
> I even pulled a request to define these OIDs in Botan...
> So thanks to have done that!
> 
> ___
> 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] Genart telechat review of draft-ietf-mmusic-sdp-bundle-negotiation-49

[Alissa Cooper]

Linda, thanks for your reviews. I have entered a No Objection ballot.

Alissa

> On Apr 3, 2018, at 4:41 PM, Linda Dunbar  wrote:
> 
> Reviewer: Linda Dunbar
> 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-mmusic-sdp-bundle-negotiation-??
> Reviewer: Linda Dunbar
> Review Date: 2018-04-03
> IETF LC End Date: 2018-02-14
> IESG Telechat date: 2018-04-19
> 
> Summary:
> The document is written very clear, easy to understand even for people like me
> who is not an expert in the media transport. A dump question, is "media
> description" same as a "media flow"? Is it always one to one mapping?
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> 
> ___
> 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] Genart telechat review of draft-ietf-opsawg-mud-20

[Alissa Cooper]

Robert, thanks for your review. Eliot, thanks for addressing Robert’s comments. 
I have entered a Yes ballot.

Alissa

> On Apr 12, 2018, at 8:17 AM, Eliot Lear  wrote:
> 
> Hi Robert and everyone else,
> 
> Circling for a landing here...
> 
> On 11.04.18 18:15, Robert Sparks wrote:
>> With this, I'm puzzled about the use of the word standardized at all. I 
>> think I'm hearing that you expect MUD controllers to know about some 
>> well-known classes by convention and that groups like fairhair or someone 
>> else might make a list of classes that MUD controllers might collectively 
>> decide to build in knowledge of. Am I getting closer to the right picture? 
>> (This is opposed to a set of classes that are created by a standards action 
>> and listed in a registry somewhere).
> 
> I've attempted to clarify this language as we discussed.  On the point of 
> standardization, I've made a clean separation:
> URNs: standardized (and therefore hopefully well documented) behaviors, such 
> as DNS and NTP.
> URIs that take the form of URLs.  These are just class names that the 
> administrator has to fill out, or are otherwise somehow pre-populated.
> I hope that this resolves any lingering confusion.
> 
> Thanks again for working to improve this document.  I really appreciate it!
> 
> Eliot
> ___
> 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

[Gen-art] Genart last call review of draft-ietf-acme-acme-11

[Dale Worley]

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.

For more information, please see the FAQ at
.

Document:  draft-ietf-acme-acme-11
Reviewer:  Dale R. Worley
Review Date:  2018-04-18
IETF LC End Date:  2018-04-18
IESG Telechat date:  2018-05-10

Summary:

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

This draft is much better than the version (-08) that I previously was
the assigned Gen-ART reviewer for.  The overall work and exposition
are quite solid, though there are some open technical issues that need
to be resolved.

* Technical issues

What is the versioning and extensibility system?  -- It seems that the
natural approach is that structures returned by fetches of Acme
resources may contain elements that are not defined in this document,
and a client should ignore them if it doesn't understand them.  This
allows plenty of flexibility for extending the Acme protocol; in
particular, by adding further resources to the directory object.

The handling of "terms of service agreement" seems to be insufficient,
in that none of the information passed around says *what* agreement
the client has agreed to.  The client only sends
"termsOfServiceAgreed:true" in a request, leaving what has been agreed
to unspecified -- and unauditable.  One possibility is to add an
argument for the client to provide the URL from which it fetched the
ToS (so the server knows what agreement the client is referring to)
and the hash of the ToS document (so the client must attest to what
the agreement text was).

6.6.1.  Subproblems

What error type should be used in a problem document when there are
subproblem documents?  It seems that in this situation, the intention
is that the top-level problem document is not intended to carry error
information itself, so you want to define a "subproblems" error type,
to use when there is no natural overall error type.

* Editorial issues

7.1.  Resources

The position of "newNonce" in the diagram is strange.  Does it have a
different relationship to the directory resource than newAccount,
etc.?  Similarly for the "finalize" and "cert" URLs of an order
object. -- Reading further in the draft suggests that the graphical
difference indicates that that these values are optional in the
respective objects, although the text doesn't identify that.

7.1.2.  Account Objects

   contact (optional, array of string):  An array of URLs that the
  server can use to contact the client for issues related to this
  account.  For example, the server may wish to notify the client
  about server-initiated revocation or certificate expiration.

I mentioned this in my review of -08, but it hasn't been fixed:
Strictly, you want "URIs" here, as tel:, sip:, and mailto: URIs are
not URLs [RFC 6068].

7.3.5.  External Account Binding

   To enable ACME account binding, a CA needs to provide the ACME client
   with a MAC key and a key identifier, using some mechanism outside of
   ACME.  The key identifier MUST be an ASCII string.  The MAC key
   SHOULD be provided in base64url-encoded form, to maximize
   compatibility between non-ACME provisioning systems and ACME clients.

I *think* what this means is that the service providing the external
account provides the ACME client with a MAC key and a key identifier,
which the client then uses in constructing its request to the ACME
server.  If that is correct, this text is not making clear (to me) the
distinction between the CA that operates the ACME server (which I take
as the default meaning of "CA" in this document) and the service that
provides the "external account".  I think two different terms are
needed for the two services so as to make the processing described in
this section clear.

7.4.  Applying for Certificate Issuance

This section seems to describe both the process of creating an order
and the process of finalizing an order.  The initial paragraphs regard
creating an order, but the text starting with "Once the client
believes it has fulfilled the server's requirements..." it talks about
finalization.  The text continues to discuss finalization until it
gets to this confusing item:

   o  "ready": The server agrees that the requirements have been
  fulfilled, and is awaiting finalization.  Submit a finalization
  request.

I *think* what is going on is that the text from "The status of the
order will indicate..." through the 5 following items are a *general*
description of the status field which is limited to neither the order
creation step nor the order finalization step.

It seems to me that this section should be divided into three parts,
one describing creating an order, one describing finalizing an 

Re: [Gen-art] Fwd: Re: Gen-art LC Review of? draft-ietf-anima-autonomic-control-plane-13

[Toerless Eckert]

Sorry, trying to get through backlog. Took longer than expected...

On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote:
> Hi.
> It has been about 6 weeks since responses to the review were postponed till 
> after IETF 101 any thoughts yet?
> Regards,Elwyn
> 
> 
> Sent from Samsung tablet.
>  Original message From: Elwyn Davies  
> Date: 02/03/2018  12:04  (GMT+00:00) To: Brian E Carpenter 
> , gen-art@ietf.org Cc: 
> draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: [Gen-art] 
> Gen-art LC Review of
>   draft-ietf-anima-autonomic-control-plane-13 
> Just taking up one point for the time being  
> Even if the reference model is informational, I was relying on RFC 8067, s1, 
> para 3:
>    Section 2 of [RFC3967] lists some conditions under which downrefs may
>    make sense.  In addition to those, it has become common for working
>    groups to produce foundational documents (which contain important
>    information such as terminology definitions and architectural design
>    and considerations) at Informational status, and those documents are
>    often needed as normative references in the Standards Track protocol
>    documents that follow. 
> I would say that sombody implementing ACP really needs to have read and 
> understood the reference model and so I would argue:1. That it needs to be 
> normative,and2. The downref is sanctioned by the language in RFC 8067. 
> I am on holiday for a week and others are fighting the draft deadline so 
> perhaps we can postpone discussion of the other points until the draft panic 
> has subsided.
> Cheers,Elwyn
> Sent from Samsung tablet.

-- 
---
t...@cs.fau.de

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

[Gen-art] Fwd: Re: Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13

[Elwyn Davies]

Hi.
It has been about 6 weeks since responses to the review were postponed till 
after IETF 101 any thoughts yet?
Regards,Elwyn


Sent from Samsung tablet.
 Original message From: Elwyn Davies  
Date: 02/03/2018  12:04  (GMT+00:00) To: Brian E Carpenter 
, gen-art@ietf.org Cc: 
draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: [Gen-art] 
Gen-art LC Review of
  draft-ietf-anima-autonomic-control-plane-13 
Just taking up one point for the time being  
Even if the reference model is informational, I was relying on RFC 8067, s1, 
para 3:
   Section 2 of [RFC3967] lists some conditions under which downrefs may
   make sense.  In addition to those, it has become common for working
   groups to produce foundational documents (which contain important
   information such as terminology definitions and architectural design
   and considerations) at Informational status, and those documents are
   often needed as normative references in the Standards Track protocol
   documents that follow. 
I would say that sombody implementing ACP really needs to have read and 
understood the reference model and so I would argue:1. That it needs to be 
normative,and2. The downref is sanctioned by the language in RFC 8067. 
I am on holiday for a week and others are fighting the draft deadline so 
perhaps we can postpone discussion of the other points until the draft panic 
has subsided.
Cheers,Elwyn
Sent from Samsung tablet.___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Last Call review of draft-ietf-curdle-des-des-des-die-die-die-05

[Meral Shirazipour]

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-curdle-des-des-des-die-die-die-05
Reviewer: Meral Shirazipour
Review Date: 2018-04-18
IETF LC End Date: 2018-04-24
IESG Telechat date: NA


Summary: This draft is ready to be published as BCP RFC but has some nits.

Major issues:

Minor issues:

Nits/editorial comments:

-[Page 4], "prevalance"--->"prevalence"
-[Page 5], "implementions"--->"implementations"
-[Page 5], "aministrators"--->"administrators"
-[Page 7], "accelleration"--->"acceleration"

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com
___
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-ippm-twamp-yang-07

[Mahesh Jethanandani]

Pete,

Thank for your review. I will address the remaining comments on the draft.

> On Apr 16, 2018, at 9:01 AM, Pete Resnick  wrote:
> 
> Reviewer: Pete Resnick
> 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-ippm-twamp-yang-07
> Reviewer: Pete Resnick
> Review Date: 2018-04-16
> IETF LC End Date: 2018-04-27
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> This document appears ready to go forward. The only "issue" I have here might
> end up being an editorial issue, but I list it as a Minor issue because it
> might be substantive.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> In the paragraph after Figure 3, it says, "and subsequent values are
> monotonically increasing". I'm not sure I understand what that means. If 0 is
> the highest priority, then 1 is a *lower* priority than 0, not an increasing
> priority. If you are trying to say that the numeric value of the priority 
> field
> is increasing by 1 for each subsequent value, then "monotonically increasing"
> is wrong; the sequence "0 2 5 36" is monotonically increasing. You'd say
> instead, "and subsequent values increase by one". If all you mean is that
> values start at 0 and go up from there, I think you should just delete the
> entire phrase; it doesn't add anything and strikes me as confusing.
> 
> Nits/editorial comments:
> 
> Why are RFC 4086, RFC 8018, and ietf-ippm-metric-registry Informative
> References instead of Normative? The uses appear to be normative.

Ok. Will move them to Normative section.

> 
> I'm not clear why the examples were split between Section 6 and Appendix A;
> seems like you could just use the long one in section 6 and explain only the
> important bits. I also note that neither of them make any claims about
> normativity: That is, most examples in documents I see always say something
> like, "If there is a conflict between anything here and the syntax in the
> model, the model wins." Is that not the case in these sorts of model 
> documents?

We decided to split the examples between Section 6 and Appendix A primarily 
because we wanted to focus on describing parts of the configuration in Section 
6. We kept the examples smaller and added a description up front to describes 
them, so it was easy to follow them. They can also be incomplete, specially as 
it relates to mandatory nodes. 

The examples in the Appendix are more complete and can be used to test any 
implementation of the model. 

> 
> Pet peeve: Except in Acknowledgements, I really don't like the use of "we" in
> IETF documents (even though it's becoming more and more common). It's not 
> clear
> to whom it refers (the WG? the authors? the IETF?). In most places, it can be
> replaced with "This document", or using passive voice (e.g., s/We define X 
> as/X
> is defined as). There are only 4 occurrences: Abstract, 1.1, 3, and 3.1. Easy
> enough to change.

Ok. Will do.

Thanks.

> 
> Note to shepherd: In the shepherding writeup, question 1 is not answered
> correctly. This document is going for *Proposed* Standard, not *Internet*
> Standard. Further, there is no explanation for why this should be a standards
> track document (though I believe the answer is pretty straightforward). You
> should go correct that. While you're at it, you can update answer 15, as that
> nit was corrected.
> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [Gen-art] [ippm] Genart last call review of draft-ietf-ippm-twamp-yang-07

[MORTON, ALFRED C (AL)]

Hi Pete, for your Minor Issue:

> -Original Message-
> From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Pete Resnick
> Sent: Monday, April 16, 2018 12:02 PM

> Minor issues:
> 
> In the paragraph after Figure 3, it says, "and subsequent values are
> monotonically increasing". I'm not sure I understand what that means. If 0 is
> the highest priority, then 1 is a *lower* priority than 0, not an increasing
> priority. If you are trying to say that the numeric value of the priority 
> field
> is increasing by 1 for each subsequent value, then "monotonically increasing"
> is wrong; the sequence "0 2 5 36" is monotonically increasing. You'd say
> instead, "and subsequent values increase by one". If all you mean is that
> values start at 0 and go up from there, I think you should just delete the
> entire phrase; it doesn't add anything and strikes me as confusing.
> 
[acm] I seem to recollect that we arrived at this sentence after 
explaining the inverse relationship between values and priorities along the way.
Surely, someone has done this before, and co-authors welcome other
concise text suggestions.

OLD
   The client container holds a list (mode-preference-chain) which
   specifies the Mode values according to their preferred order of use
   by the operator of this Control-Client, including the authentication
   and encryption Modes.  Specifically, mode-preference-chain lists the
   mode and its corresponding priority, expressed as a 16-bit unsigned
   integer, where zero is the highest priority and subsequent values are
   monotonically increasing.

NEW
   The client container holds a list (mode-preference-chain) which
   specifies the Mode values according to their preferred order of use
   by the operator of this Control-Client, including the authentication
   and encryption Modes.  Specifically, mode-preference-chain lists the
   mode and its corresponding priority, expressed as a 16-bit unsigned
   integer, where zero is the highest priority and subsequent integers 
   increase by one.

Does that do it? 
Al


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