Re: [Gen-art] Genart last call review of draft-ietf-git-using-github-04

[Brian E Carpenter]

Thanks
   Brian

On 04-Mar-20 15:06, Alissa Cooper wrote:
> I put this in an RFC Editor note.
> Alissa
> 
>> On Feb 24, 2020, at 11:04 AM, Martin Thomson  wrote:
>>
>> Thanks Brian,
>>
>> On Sun, Feb 23, 2020, at 17:01, Brian Carpenter via Datatracker wrote:
>>> Is this draft intended to become part of BCP25? I think it would be
>>> useful for the IESG to clarify this rather than leave it to the RFC Editor.
>>
>> This is a good question.  Given the intended status of BCP, I would say that 
>> integrating into 25 is better than creating a new number.  I don't know how 
>> to best signal this intent though.
>>
>> And I fixed the nit in the copy on GitHub.
>>
>> ___
>> 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 last call review of draft-ietf-git-using-github-04

[Alissa Cooper]

I put this in an RFC Editor note.
Alissa

> On Feb 24, 2020, at 11:04 AM, Martin Thomson  wrote:
> 
> Thanks Brian,
> 
> On Sun, Feb 23, 2020, at 17:01, Brian Carpenter via Datatracker wrote:
>> Is this draft intended to become part of BCP25? I think it would be
>> useful for the IESG to clarify this rather than leave it to the RFC Editor.
> 
> This is a good question.  Given the intended status of BCP, I would say that 
> integrating into 25 is better than creating a new number.  I don't know how 
> to best signal this intent though.
> 
> And I fixed the nit in the copy on GitHub.
> 
> ___
> 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-avtcore-multiplex-guidelines-11

[Alissa Cooper]

Vijay, thanks for your reviews. Authors, thanks for your responses. I entered a 
No Objection ballot.

Alissa


> On Feb 25, 2020, at 1:00 AM, Roni Even (A)  wrote:
> 
> Vijay thanks,
> The document will be published as an Informational RFC and not a proposed 
> standard.
> Roni
> 
>> -Original Message-
>> From: Vijay Gurbani via Datatracker [mailto:nore...@ietf.org]
>> Sent: Monday, February 24, 2020 6:45 PM
>> To: gen-art@ietf.org
>> Cc: draft-ietf-avtcore-multiplex-guidelines@ietf.org; a...@ietf.org; 
>> last-
>> c...@ietf.org
>> Subject: Genart telechat review of draft-ietf-avtcore-multiplex-guidelines-11
>> 
>> Reviewer: Vijay Gurbani
>> 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-avtcore-multiplex-guidelines-11
>> Reviewer: Vijay K. Gurbani
>> Review Date: 2020-02-24
>> IETF LC End Date: None
>> IESG Telechat date: 2020-03-05
>> 
>> Summary: This document is read for publication as a Proposed Standard.  I
>> had reviewed version -08, and all of my comments from that version have
>> been addressed in -11.  I have no further comments.
>> 
>> Major issues: 0
>> 
>> Minor issues: 0
>> 
>> Nits/editorial comments: 0
>> 
>> 
> 
> ___
> 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 last call review of draft-ietf-dmm-pmipv6-dlif-04

[Alissa Cooper]

Ines, thanks for your review. Carlos, thanks for your response. I entered a No 
Objection ballot.

Alissa


> On Nov 2, 2019, at 7:44 AM, CARLOS JESUS BERNARDOS CANO  
> wrote:
> 
> Hi Ines,
> 
> We've just posted a new revision addressing your comments.
> 
> Thanks,
> 
> Carlos
> 
> On Fri, Oct 18, 2019 at 1:21 PM CARLOS JESUS BERNARDOS CANO  > wrote:
> Hi Ines,
> 
> Thanks for the review. We'll check with IANA folks about how to add more 
> details (whether they do it or we do).
> 
> Thanks,
> 
> Carlos
> 
> On Mon, Oct 14, 2019 at 10:21 PM Ines Robles via Datatracker 
> mailto:nore...@ietf.org>> wrote:
> Reviewer: Ines Robles
> 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-dmm-pmipv6-dlif-04
> Reviewer: Ines Robles
> Review Date: 2019-10-14
> IETF LC End Date: 2019-10-14
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> I believe the draft is technically good. This document is well written.
> 
> The document proposes Distributed Mobility Management for Proxy Mobile IPv6 in
> which mobility sessions are anchored at the last IP hop router called MAAR
> (mobility anchor and access router). The document focuses on the required
> extensions to effectively support simultaneously anchoring several flows at
> different distributed gateways.
> 
> I have a minor concern detailed in Nits section.
> 
> Major issues:Not Issues found
> 
> Minor issues: Not Issues found
> 
> Nits/editorial comments:
> 
> It would be nice to specify IANA Section with more details, such as indicating
> the registry which the option type belong, etc. [rfc8126]
> 
> Thank you for this document,
> 
> Ines.
> 
> 
> 
> 
> -- 
> Special Issue "Beyond 5G Evolution": 
> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g 
> 
> 
> 
> 
> -- 
> Special Issue "Beyond 5G Evolution": 
> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g 
> 
> 
> ___
> 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] Last Call review of draft-ietf-dmm-distributed-mobility-anchoring-13

[Alissa Cooper]

Paul, thanks for your review. Carlos, thanks for your response. I entered a No 
Objection ballot.

Alissa


> On Nov 1, 2019, at 8:06 AM, CARLOS JESUS BERNARDOS CANO  
> wrote:
> 
> Dear Paul,
> 
> We've just posted a new revision (-14) addressing all your comments.
> 
> Thanks!
> 
> Carlos
> 
> On Fri, Oct 18, 2019 at 1:07 PM CARLOS JESUS BERNARDOS CANO  > wrote:
> Dear Paul,
> 
> Thanks for the review.
> 
> We will fix the outdated references in the next version of the doc 
> (addressing also other directorate reviews that might arrive).
> 
> Carlos
> 
> On Sat, Oct 12, 2019 at 8:38 PM Paul Kyzivat  > 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-dmm-distributed-mobility-anchoring-13
> Reviewer: Paul Kyzivat
> Review Date: 2019-10-12
> IETF LC End Date: 2019-10-14
> IESG Telechat date: ?
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits that should 
> be fixed before publication.
> 
> General:
> 
> I found that I lack the subject matter expertise to meaningfully review 
> this document. I read it carefully, along with one of the references. 
> But it appeared that I would need to internalize quite a number of other 
> references before it would be possible to really follow this.
> 
> I did review it for form - the document is well written. (Most documents 
> that I review have at least a few problems with form.)
> 
> IdNits returns a couple of outdated references that should be cleaned up:
> 
>== Outdated reference: A later version (-18) exists of
>   draft-ietf-dmm-ondemand-mobility-17
> 
>== Outdated reference: A later version (-02) exists of
>   draft-ietf-rtgwg-atn-bgp-01
> 
> I have no other comments.
> 
> 
> -- 
> Special Issue "Beyond 5G Evolution": 
> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g 
> 
> 
> 
> 
> -- 
> Special Issue "Beyond 5G Evolution": 
> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g 
> 
> 
> ___
> 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 last call review of draft-ietf-calext-jscalendar-25

[Barry Leiba]

Robert, thanks for the careful (as always) review.

Just on one point -- the authors can reply to the others:

> It doesn't look like application/jscalendar+json has had a media type review.

There aren't formal media-type reviews for types registered in
IETF-consensus documents: see Section 3.1 of RFC 6838.

That said, Section 5.1 of 6838 says this:

   Notice of a potential media type registration in the standards tree
   SHOULD be sent to the media-ty...@iana.org mailing list for review.
   This mailing list has been established for the purpose of reviewing
   proposed media and access types.

I strongly encourage the authors to follow the advice in that section
now: it's not too late.  And I'm sorry that I didn't catch that
myself; thanks for picking it up.

Barry

___
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-calext-jscalendar-25

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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-calext-jscalendar-25
Reviewer: Robert Sparks
Review Date: 2020-03-03
IETF LC End Date: 2020-03-09
IESG Telechat date: Not scheduled for a telechat

Summary: This document has minor issues to address before being published as a
Proposed Standard RFC.

Caveats: I did not carefully verify that the initial registry values (of which
there are many) matched the document text.

Minor issues:

ABNF is used, but there is no reference to RFC 5234. The document shepherd
report implies that the ABNF has not been verified (see item 19 in that report).

The first registry in section 8.4.3 should be explicit that it is a registry
for values of the "@type" property. Right now the reader has to infer that.

It's not stated clearly whether a patch should succeed or fail if the resulting
object doesn't meet this specification's requirements. Side question: if a
patch changes 'updated' (4.1.6) in an object that didn't already have a
'created' (4.1.5), should it fail if it doesn't also result in an object that
has a 'created'? Or is it ok to lose the original creation time information?

The security consideration section only points to section 7 of RFC 3986 for
potential issues related to the URIs that can be carried in this
representation. I don't think that's sufficient. There should be some
discussion (or a pointer to discussions) about the potential for malicious
construction of jscalendar objects containing potentially very large numbers of
URIs in, say, as Link objects (4.2.7). Is there an opportunity for amplified
attacks here? (Especially if these URLs might be automatically referenced by
any client, and even more so if the object is sent from a calendar with a large
number of subscribers.)

Have you considered any tighter integrity checking for (4.2.7) links? Maybe a
checksum property?

It doesn't look like application/jscalendar+json has had a media type review.

Nits:

Introduction, second sentence: "It" is ambiguous. As written, it could point to
"This document" or "a data model". You sort of mean the later, but I think you
really mean the JSON representation (especially when you say "process"), but
you don't talk about that here.

Introduction, design considerations list, last bullet: This bullet is currently
written as description of the end result, not as a design consideration. Please
restate it to match the rest of the elements in the list.

Last full paragraph on page 2: "unlike most common JSON data representations"
is asserted without data. The document doesn't really need it. I suggest simply
deleting the phrase from the sentence.

I don't expect anything to change at this point, but I do have to point to the
dissonance in the conventions A[] and A[B]. It would have been far less
confusing for A have the same semantic in both cases (preferably value), than
the current situation where it means value for A[], but key for A[B].

1.4.3 last paragraph: You don't need to use MUST in this example - it's not a
requirement on the protocol. I suggest replacing "MUST be" with "is correctly".

In 4.2.5 at 'locationTypes', it would be better to point to the actual registry
(https://www.iana.org/assignments/location-type-registry/location-type-registry.xhtml)
than only to RFC4589.

Do you want to say anything about what should happen if the size of a resource
(as represented by 'size' in 4.2.7) doesn't match the actual fully decoded
size? I think you mean for this property to be an informational estimate, and
you should explicitly say the actual size could be quite different.

In 4.2.10, 'american-football""' should be 'american-football"' (one fewer ")

In 4.3.2 at 'byDay', why do you have * symbols around 'An *NDay* object'?

In 4.4.5 at 'scheduleUpdated', do you really want to couple this so tightly to
iTIP? Perhaps you should say "the last time this participant provided an
update" and point to iTIP as how these are typically provided?

Major issues:

Minor issues:

Nits/editorial comments:



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

Re: [Gen-art] draft-ietf-lamps-5480-ku-clarifications-01

[Alissa Cooper]

Dale, thanks for your reviews. Sean, thanks for your responses. I entered a No 
Objection ballot. If Dale’s questions can be clarified for non-expert readers, 
I think that would be good.

Alissa


> On Mar 1, 2020, at 11:00 PM, Dale R. Worley  wrote:
> 
> Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points
> occur to me:
> 
>   1.  Introduction
> 
>   This document corrects this omission, by updating Section 3 of
>   [RFC5480] to make it clear that neither keyEncipherment nor the
>   dataEncipherment key usage bits are set for key agreement algorithms.
> 
> I think it would be more accurate to say something like "neither ... are
> set in certificates that specify key agreement algorithms" -- usage bits
> are logically a component of a certificate rather than a feature of an
> algorithm.
> 
> But it's unclear to me whether id-ecPublicKey is only used in key
> agreement certificates.  RFC 5480 states that if the cert uses id-ecDH
> or id-ecMQV and provides keyUsage, then keyAgreement must be set.  So
> it's clear that certs with id-ecDH or id-ecMQV are key agreement certs.
> But RFC 5480 says that if the cert lists id-ecPublicKey, then
> keyAgreement is optional.  That suggests to me that some certs can use
> id-ecPublicKey without being key agreement certs.  In turn, section 1 of
> this I-D suggests the I-D is not intended to apply to those certs, but
> section 3 seems to apply to them anyway.
> 
> To try to distill it to one sentence:  Can id-ecPublicKey appear in
> certs that are not for key agreement, and if so, are keyEncipherment and
> dataEncipherment allowed in the keyUsage of those certs?
> 
>   3.  Updates to Section 3
> 
>   If the keyUsage extension is present in a certificate that indicates
>   in SubjectPublicKeyInfo, then following values MUST NOT be present:
> ---^
> 
> Is "id-ecPublicKey" missing here?
> 
>   If the keyUsage extension is present in a certificate that indicates
>   id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
>   values also MUST NOT be present:
> 
> Is it a fact that all certificates with these three algorithms are
> certificates for key agreement?  If so, it would be nice to state that
> either in section 3 or section 1, to show how section 3 is connected
> with "for key agreement algorithms" in section 1.  Otherwise, the
> connection between the two requires information that is stated
> elsewhere.
> 
> Dale
> 
> ___
> 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 last call review of draft-ietf-rmcat-wireless-tests-08

[Alissa Cooper]

Gyan, thanks for your review. Ziaoqing, thanks for your responses. I entered a 
No Objection ballot.

Alissa


> On Feb 27, 2020, at 12:36 PM, Xiaoqing Zhu (xiaoqzhu) 
>  wrote:
> 
> Hi Gyan, 
> 
> Thanks a lot for your very thorough review of this draft, and for your 
> valuable comments. We have uploaded the revised version (-09) to address some 
> of the concerns and suggestions you've raised. 
> 
> Please also see our replies below inline, tagged [authors].  Let us know if 
> you have any further thoughts or comments __ 
> 
> Best Regards,
> Xiaoqing, on behalf of all authors.
> 
> 
> On 1/21/20, 3:46 PM, "Gyan Mishra via Datatracker"  wrote:
> 
>Reviewer: Gyan Mishra
>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
> 
>.
> 
>Reviewer: Gyan Mishra
>Review result: Ready with Minor Issues
> 
>Document: draft-ietf-rmcat-wireless-tests-08
>Reviewer: Gyan Mishra
>Review Date: 2020-01-17
>IETF LC End Date: 2020-01-21
>IESG Telechat date: Not scheduled for a telechat
> 
>Summary: Ready, but with nits and minor issues that should be addressed.
> 
>Major issues: None
> 
>Minor issues:  This document describes test cases for evaluating 
> performance of
>RTP congestion control algorithms over LTE & WIFI networks.
> 
>Section 1 It is mentioned a number of instance where “wired” is mentioned 
> where
>I believe “wireless” or “WIFI” is what is meant to be stated.  Please 
> check.
> 
> [authors] Thanks for raising this concern. We’ve doubled checked on the usage 
> of “wired” in all three instances in the introduction section, and believe it 
> is intended as such.  Our intention was to contrast the characteristics of 
> wireless networks from those of wired networks, as a motivation of the need 
> for this draft.   We have, however, taken the opportunity to revise those 
> sentences to make them less wordy.
> 
>I would recommend  to use WIFI to refer to local LAN WIFI and use cellular 
> to
>refer to a mobile handset, and not use the term “wireless” as that could be
>confusing.
> 
> [authors] We agree with the suggestion that it is preferable to refer 
> specifically to WiFi or cellular whenever possible and have mostly edited out 
> the word “wireless”. In a few places, however, it is rather cumbersome to 
> always say “cellular and WiFi networks” when our intention is to simply 
> contrast the difference between wireless and wired communication. We have 
> therefore stuck with the term “wireless” in those cases.
> 
>I would recommend not using LTE to refer to Cellular from a general mobile
>handset point of view, since LTE refers to 4G and Cellular could be any -
>2G,3G,4G,5G etc
> 
> [authors]  We agree with this proposed change. The text has been updated 
> accordingly with a few exceptions: a) mentioning LTE/5G as an example of 
> operational cellular network; b) pointing to the LTE simulator in NS-3; and 
> c) referencing the corresponding 3GPP standard documents.
> 
>Section 3 This section also mentioned “wired” where I think the goal of the
>document is test cases of WIFI & Cellular and adding in wired does confuse 
> the
>reader as we are talking about quality degradation issues with wireless
>technologies - WIFI & Cellular.  Please check the verbiage.
> 
> [authors] Thanks for pointing this out. We have checked all three previous 
> usage of the word in this section and have eliminated the mention of it in 
> the introductory discussions. The remaining two uses, however, are needed for 
> describing the proposed test case topology so we left them as is.
> 
>Section 3 In this sentence you mention 3G support of high bandwidth.  My
>experience with 3G has not been very slow page loading and that multimedia
>would suffer.
> 
> [authors] This is a fair complaint. To avoid controversy, we have revised the 
> sentence to now state: “… it is evident that only the more recent radio 
> technologies can support the high bandwidth requirements  …”
> 
> 
>Section 3 Bottom of page 5 it is mentioned that the combination of multiple
>access technologies such as one user has LTE connection and another has 
> Wi-Fi
>connection is kept out of the scope of this document.  Please explain why 
> as
>the reader would believe it would be in scope as that is the main topic.
> 
> [authors]  When some of the users are on LTE and some of the users are on 
> Wi-Fi, it is only interesting to investigate the test case when the 
> bottleneck of the system is on the wired hop.  Whereas the main focus of this 
> draft is to evaluate how congestion control schemes interacti

Re: [Gen-art] Genart last call review of draft-ietf-rmcat-eval-criteria-11

[Alissa Cooper]

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

Alissa


> On Feb 13, 2020, at 7:44 PM, Joel Halpern via Datatracker  
> wrote:
> 
> Reviewer: Joel Halpern
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-rmcat-eval-criteria-11
> Reviewer: Joel Halpern
> Review Date: 2020-02-13
> IETF LC End Date: 2020-02-26
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as an Informational RFC
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments: N/A
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
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-ntp-packet-timestamps-07

[Alissa Cooper]

Russ, thanks for your review. Tal, thanks for addressing Russ’ review. I 
entered a No Objection ballot.

Best,
Alissa


> On Feb 16, 2020, at 9:20 AM, Tal Mizrahi  wrote:
> 
> Hi Russ,
> 
> Many thanks for the thorough review.
> 
> Please see the proposed changes below and let us know if they make
> sense. If there are no further comments we will implement these
> changes along with other changes following IETF last call.
> 
> Cheers,
> Tal.
> 
> 
> On Fri, Feb 7, 2020 at 9:42 PM Russ Housley via Datatracker
> mailto:nore...@ietf.org>> wrote:
>> 
>> Reviewer: Russ Housley
>> Review result: Almost 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-ntp-packet-timestamps-07
>> Reviewer: Russ Housley
>> Review Date: 2020-02-07
>> IETF LC End Date: 2020-02-20
>> IESG Telechat date: Unknown
>> 
>> 
>> Summary: Almost Ready
>> 
>> Major Concerns: None
>> 
>> 
>> Minor Concerns:
>> 
>> Abstract: It is too long.  In my opinion, the second paragraph should
>> be moved to the Introduction.
> 
> [TM] Agreed.
> 
>> 
>> 
>> Section 2.1: Please use:
>> 
>>   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.
>> 
> 
> [TM] Agreed.
> 
>> 
>> Section 2.3, paragraph 1: I think it would be better to define timestamp
>> error without using the phrase "device under test".  If you disagree,
>> please add a definition for "device under test".
>> 
> 
> [TM] We propose the following text update:
> OLD:
> Timestamp error: The difference between the timestamp value at the
> device under test and the value of a reference clock at the same time
> instant.
> NEW:
> Timestamp: A value that represents a point in time, corresponding to
> an event that occurred or is scheduled to occur.
> Timestamp error: The difference between the timestamp value and the
> value of a reference clock at the time of the event that the timestamp
> was intended to indicate.
> 
> 
>> 
>> Section 3, Synchronization aspects: The paragraph should also say that
>> there might not be any synchronization considerations.  For example, an
>> epoch since the device was powered up does not have any.
>> 
> 
> 
> [TM] We propose the following text update:
> OLD:
> Synchronization aspects:
> 
> The specification of a network protocol that makes use of a packet
> timestamp is expected to include the synchronization aspects of using
> the timestamp. While the synchronization aspects are not strictly part
> of the timestamp format specification, these aspects provide the
> necessary context for using the timestamp within the scope of the
> protocol. Further details about synchronization aspects are discussed
> in Section 5.
> 
> NEW:
> Synchronization aspects:
> 
> The specification of a network protocol that makes use of a packet
> timestamp is expected to include the synchronization aspects of using
> the timestamp. While the synchronization aspects are not strictly part
> of the timestamp format specification, these aspects provide the
> necessary context for using the timestamp within the scope of the
> protocol. In some cases timestamps are used without synchronization,
> e.g., a timestamp that indicates the number of seconds since power up.
> In such cases the Synchronization Aspects section will specify that
> the timestamp does not correspond to a synchronized time reference,
> and may discuss how this affects the usage of the timestamp. Further
> details about synchronization aspects are discussed in Section 5.
> 
> 
>> 
>> Section 9:  Please say "such as Message Authentication Codes (MAC)".
>> HMAC is one instance of a MAC, and you are not trying to name a specific
>> algorithm here.
>> 
> 
> [TM] Agreed.
> 
>> 
>> Section 11.2:  RFC 1323 has been obsoleted by RFC 7323.  Is there a
>> reason that it is better ot reference the older document here?
>> 
> 
> [TM] Agreed.
> 
>> 
>> Nits:
>> 
>> General: Some places this Internet-Draft refers to itself as "this memo"
>> and other places if refers to itself as "this document".  Please pick.
>> 
> 
> [TM] Agreed.
> 
>> 
>> Section 1, paragraph 1: Nonces often have a timestamp embedded in them.
>> For example, TLS 1.2 [RFC5246] defined the nonce as:
>> 
>> struct {
>> uint32 gmt_unix_time;
>> opaque random_bytes[28];
>> } Random;
>> 
>> So, I think the paragraph should include something about using time to
>> create an unlikely to repeat value.
>> 
> 
> [TM] We propose the following tex

Re: [Gen-art] Genart telechat review of draft-ietf-ecrit-data-only-ea-21

[Alissa Cooper]

Mohit, thanks for your reviews. Brian, thanks for your response. I entered a 
Yes ballot. Glad to finally see this getting done!

Alissa


> On Feb 27, 2020, at 10:44 PM, Mohit Sethi via Datatracker  
> wrote:
> 
> Reviewer: Mohit Sethi
> 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-ecrit-data-only-ea-21
> Reviewer: Mohit Sethi
> Review Date: 2020-02-27
> IETF LC End Date: 2019-09-02
> IESG Telechat date: 2020-03-05
> 
> Summary: My comments on version -18 were addressed. The document is ready. 
> 
> 
> ___
> 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