Re: [Gen-art] Genart last call review of draft-kucherawy-rfc8478bis-03

[Alissa Cooper]

Joel, thanks for your review. Yann, thanks for your response. I entered a No 
Objection ballot. One comment below.

> On Dec 30, 2019, at 2:19 PM, Yann Collet  wrote:
> 
>> I assume that the "last block" flag is the least significant bit of the 
>> first byte of the block header?  
> 
> Yes, this is correct
> 
>> And Literals_Block_Type is the least significant two bits of the first byte 
>> of the Literals_Section_Header?
> 
> Yes, this is correct too.
> 
>> Should this be stated more explicitly? 
> 
> In both cases, the bitfield is preceded by the mention "little-endian" :
> 
> - " Block_Header uses 3 bytes, written using little-endian convention. It 
> contains 3 fields "
> - Literals_Section_Header: "It's a byte-aligned variable-size bitfield, 
> ranging from 1 to 5 bytes, using little-endian convention."
> 
> "Little-endian" was presumed a "good enough" indication that the first byte 
> is the lowest one.
> After that, the "lowest bit" becomes the least significant bit of the first 
> byte.
> 
> Nevertheless, if this is deemed not clear enough, 
> some additional statement could be added to make the specification more 
> explicit.

I think this is clear enough in the spec.

Thanks,
Alissa


> 
> 
> 
> On 12/26/19, 17:16, "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.
> 
>Document: draft-kucherawy-rfc8478bis-03
>Reviewer: Joel Halpern
>Review Date: 2019-12-26
>IETF LC End Date: 2020-01-17
>IESG Telechat date: Not scheduled for a telechat
> 
>Summary: This review primarily focused on the differences, which seem
>appropriate, from the RFC.
> 
>Major issues: N/A
> 
>Minor issues: N/A
> 
>Nits/editorial comments:
>I presume that bits within a byte are still interpreted in the normal
>fashions since we do not work in terms of the serialization of bits on 
> a
>wire, and in fact different wires may do it differently.  This does 
> leave
>the question of how bit fields are interpreted when they describe bits
>within a byte.  Thus, I assume that the "last block" flag is the least
>significant bit of the first byte of the block header?  And
>Literals_Block_Type is the least significant two bits of the first 
> byte of
>the Literals_Section_Header?  (I presume that the use of little-endian
>encoding is due to existing practice, and therefore presume it is what 
> this
>needs to describe.)   Should this be stated more explicitly?
> 
> 
> 
> 
> ___
> 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] Gen-ART Telechat review of draft-spinosa-urn-lex-13

[Alissa Cooper]

Paul, thanks for your review. I have cc’ed you on my DISCUSS ballot.

Best,
Alissa


> On Feb 18, 2020, at 1:29 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 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 <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-spinosa-urn-lex-13
> Reviewer: Paul Kyzivat
> Review Date: 2020-02-18
> IETF LC End Date: 2017-09-14
> IESG Telechat date: 2020-02-18
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> General:
> 
> I did a Last Call review on version -11 three years ago. Given the amount of 
> time that has passed, and the extent of changes, I'm surprised that there 
> wasn't another Last Call prior to scheduling the Telechat!
> 
> I had difficulty classifying the severity of the issues. Individually most of 
> them may be minor, but in aggregate they imply that IMO the document still 
> requires a lot of work.
> 
> Issues:
> 
> Major: 1
> Minor: 15
> Nits:  2
> 
> 1) MAJOR: Structure & ordering of the document
> 
> In spite of my earlier experience with this document I found it very 
> difficult to read in a single front to back pass. In retrospect, I think it 
> would have made much more sense if I had read Section 7 first.
> 
> A major problem was that I got the impression it was a goal that an arbitrary 
> legal document reader should be able to construct a valid LEX URN to that 
> document from information readily available to him, typically in the body of 
> the document itself. Yet I found many places where terms must be chosen in 
> ways that are not deterministic.
> 
> In retrospect, especially after reading Section 7, I tentatively reached the 
> conclusion that my first impression was wrong. Instead, it appears that an 
> expert (probably within the Jurisdiction Registrar) must choose the LEX URN 
> representation(s) for the legal document. This can then be incorporated into 
> the document and/or some metadata about the document that is potentially 
> available to those who later have need to reference the document.
> 
> I'm not sure I'm right about this. How this is intended to work should be 
> spelled out early in the document. I suggest moving Section 7 early in the 
> document, and elaborating it to cover this.
> 
> Section 3 (Registration Template) is very hard to follow when reading the 
> document front to back. Understanding it requires information that hasn't yet 
> been provided. In particular, section 3.1 gives an overview of the syntax of 
> 'jurisdiction', but not for 'local-name'. It then goes on to present examples 
> of full lex URNs.
> 
> I suggest that it would be helpful to move sections 2 and 3 to a position 
> later in the document - somewhere after section 5. Near or in Section 11 
> (IANA considerations) would be a good place.
> 
> 2) MINOR(?): Encoding national characters and diacritic signs
> 
> Section 4.4 has guidelines for encoding national characters and diacritic 
> signs for compatibility with DNS. I'm not qualified to evaluate whether these 
> guidelines are in agreement with best practice for DNS. If it hasn't already, 
> this document should be reviewed and approved by relevant experts.
> 
> 3) MINOR: Section 5 (Specific Syntax and Features of the LEX Identifier):
> 
> It isn't clear to me what specific components of the syntax are being 
> addressed in this section. I *think* these apply to 'jurisdiction-unit'. Can 
> you please make this clear?
> 
> I'm concerned that most of the specifications here are only RECOMMENDED. Who 
> makes the decision whether to follow these rules, and how can it be assured 
> that they are followed consistently? It is a problem if a consistent approach 
> to these isn't followed. For instance, when a reader of a document is trying 
> to create a LEX URN manually from a reference in the text, how will he know 
> whether to follow the recommendation or not?
> 
> (However, if the expectation is that an expert constructs the URN then this 
> is less of a concern.)
> 
> 4) MINOR: Annexes and Sub-Annexes:
> 
> When I read Section 6.4 the first time I was confused about the significance 
> of multiple annexes in a name - whether this refers to peer annexes of the 
> main document, or to a sub-annex of an annex. I later learned (in section 7) 
> that it means sub-annexes. This is an example of why the doc needs 
> reordering. Or else spell this out in this section.
> 
> 5) MINOR: "original" as document version
> 
> Both sections 6.6 and C1.2 discuss using "original" as the document version 
> to identify the original version of the document. But this is allowed to be 
> written in different languages. However it doesn't specify how the language 
> for this is chose

Re: [Gen-art] Genart last call review of draft-ietf-uta-tls-for-email-04

[Alissa Cooper]

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

Alissa


> On Jan 24, 2020, at 5:20 PM, Brian Carpenter via Datatracker 
>  wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready with Nits
> 
> Gen-ART Last Call review of draft-ietf-uta-tls-for-email-04
> 
> 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-uta-tls-for-email-04.txt
> Reviewer: Brian Carpenter
> Review Date: 2020-01-25
> IETF LC End Date: 2020-01-31
> IESG Telechat date:  
> 
> Summary: Ready with nit
> 
> 
> Nit:
> 
> 
>> Abstract
>> 
>>  This specification updates current recommendation for...
> 
> s/current/the current/
> 
> ___
> 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] [6tisch] Genart last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

[Alissa Cooper]

Tim, thanks for your review. Michael, thanks for your response. I entered a 
DISCUSS ballot to check on the address generation mechanism for use with SLAAC.

Best,
Alissa


> On Jan 16, 2020, at 8:21 PM, Tim Evens (tievens)  wrote:
> 
> Excellent, thanks! 
> 
> On 1/16/20, 5:03 PM, "Michael Richardson"  wrote:
> 
>Tim Evens via Datatracker  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.
> 
>Thank you.
> 
>> In section 1.2,
>> "These slots are rare, and with 10ms
>> slots, with a slot-frame length of 100, there may be only 1 slot/s
>> for the beacon."
> 
>> IMO, this could be reworded to increase clarity. For example, "Considering 
>> 10ms
>> slots and a slot-frame length of 100, these slots are rare and could result 
>> in
>> only 1 slot for a beacon."
> 
>Reworded as you suggest:
> 
> There is a limited number of timeslots designated as a broadcast slot by
> each
> -router in the network. These slots are rare, and with 10ms slots, with a
> slot-frame length of
> -100, there may be only 1 slot/s for the beacon.
> +router in the network. Considering 10ms slots and a slot-frame length of
> 100,
> +these slots are rare and could result in only 1 slot/s for a broadcast,
> which
> +needs to be used for the beacon.  Additional broadcasts for Router
> +Advertisements, or Neighbor Discovery could even more scarce.
> 
>> In section 1.3,
>> "At layer 3, [RFC4861] defines a mechanism by which nodes learn about
>> routers by listening for multicasted Router Advertisements (RA)."
> 
>> Would it be possible to reword to not use "multicasted?"  For example,
>> "by receiving multicast Router Advertisements (RA)."
> 
>done.
> 
>> "no RA is heard within a set time, then a Router Solicitation (RS) may
>> be multicast,"
> 
>> "may be sent as multicast" might be more clear.
> 
>done.
> 
>> In section 2,
>> "proxy priority  this field indicates the willingness fo the sender to
>> act as join proxy.  Lower value indicates greater willingness"
> 
>> Typo "fo"
> 
>fixed.
> 
>> IMO, it would be clearer if the field name in the protocol header
>> matches the description for it. For example, "Proxy priority (proxy prio)"
> 
>okay.
> 
>> In Section 4,
>> "An interloper with a radio sniffer would be able to use the network
>> ID to map out the extend of the mesh network."
> 
>> extend or extent?
> 
>extent, thank you catching that.
> 
>All this in -07 about to be published.
> 
> 
> 
>--
>Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> ___
> 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-nfsv4-rpcrdma-cm-pvt-data-06

[Alissa Cooper]

Suhas, thanks for your review. Chuck, thanks for your responses. I entered a No 
Objection ballot.

Best,
Alissa


> On Jan 29, 2020, at 10:43 AM, Chuck Lever  wrote:
> 
> OK. The next submitted revision will include changes resulting from
> the Gen-ART review. I'm waiting for resolution of SecDir comments
> before submitting a fresh revision.
> 
> Meanwhile, the changes so far are available to view as a diff with -06:
> 
> https://chucklever.github.io/i-d-rpcrdma-cm-pvt-data/#go.draft-ietf-nfsv4-rpcrdma-cm-pvt-data.diff
>  
> 
> 
> 
>> On Jan 29, 2020, at 10:35 AM, Suhas Nandakumar  wrote:
>> 
>> Thanks Chuck for the additional clarification. That helped me to understand 
>> better.
>> Sorry that I missed it in my reading. 
>> 
>> Yes the suggested changes look great.
>> 
>> Cheers
>> Suhas
>> 
>> On Wed, Jan 29, 2020 at 7:23 AM Chuck Lever  wrote:
>> 
>>> On Jan 29, 2020, at 12:03 AM, Suhas Nandakumar  wrote:
>>> 
>>> Thanks Chuck for the response. Please see inline
>>> 
 On Tue, Jan 28, 2020 at 7:52 AM Chuck Lever  wrote:
 
 Zero is a permitted value for the size fields. Section 5.2 explains how
 to compute the actual buffer size. If those fields contain zero, the
 actual send and receive buffer sizes would be 1024 octets.
>>> 
>>> 
>>> [Suhas] I am not sure if i am reading it right here. Section 5.2 would 
>>> result in the
>>> value of -1 if the min of the values is Zero (0/1024 - 1). Isn't it so ?
>> 
>> Section 5.2 says:
>> 
>>   Inline threshold sizes from 1KB to 256KB can be represented in the
>>   Send Size and Receive Size fields.  A sender computes the encoded
>>   value by dividing the actual value by 1024 and subtracting one from
>>   the result.  A receiver decodes this value by performing a
>>   complementary set of operations.
>> 
>> Here, "actual value" means the real size of the buffer. A 1024-octet
>> buffer would result in (1024 / 1024) - 1 = 0.
>> 
>> The computation done by the receiver is the inverse:
>> 
>>   (0 + 1) * 1024 = 1024
>> 
>> I could replace "actual value" by "buffer size, in octets". Would it
>> help if the text also spelled out the inverse computation?
>> 
>> 
>> --
>> Chuck Lever
>> 
>> 
>> 
> 
> --
> Chuck Lever
> 
> 
> 
> ___
> 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-6lo-fragment-recovery-12

[Alissa Cooper]

Peter, thanks for your review. Pascal, thanks for your response. I entered a No 
Objection ballot.

Best,
Alissa


> On Feb 18, 2020, at 10:21 AM, Pascal Thubert (pthubert)  
> wrote:
> 
> Many thanks for your review Peter!
> 
> I applied all your typo fix suggestions that are not discussed below.
> 
>> Page 14, 3rd paragraph, 1st sentence: change “a same” to one of “any”, “any
>> single”, or something similar.  These suggestions are based on the assumption
>> that fragments from disparate datagrams are not intermingled, otherwise
>> you’ll need some other description of what you want to do in order to allow
>> fragments to get a few hops away.
> 
> You're right, that can be any frame. Proposed change to:
> "
> When a single frequency is used by contiguous hops, the sender should insert 
> a delay between the frames (e.g., frames carrying fragments) that are sent to 
> the same next hop. The delay should cover multiple transmissions so as to let 
> a frame progress a few hops and avoid hidden terminal issues.
> "
> 
>> Page 18, section 7.1, inter-frame gap, 2nd sentence: change “a same” to “the
>> same” in both places in the sentence.  Overall, I couldn’t quite parse this
>> sentence.  “may be subject to receive while transmitting” left me guessing as
>> to what exactly you wanted to convey here.  Please rewrite this sentence.
> 
> Actually I did a few lines ahead but forgot to erase those : ) There's also 
> section 4.2.
> So why nit just erase the weird sentence? We then get
> 
> "
>   An implementation must control the rate at which it sends packets
>   over the same path to allow the next hop to forward a packet before
>   it gets the next.  In a wireless network that uses the same frequency
>   along a path, more time must be inserted to avoid hidden terminal
>   issues between fragments (more in Section 4.2).
> 
>   This is controlled by the following parameter:
> 
>   inter-frame gap:  Indicates the minimum amount of time between
>  transmissions.  The inter-frame gap protects the propagation of
>  one transmission before the next one is triggered and creates a
>  duty cycle that controls the ratio of air time and memory in
>  intermediate nodes that a particular datagram will use.
> "
> 
> 
> 
>> Page 19, OptFragmentSize
> Delete “of” before “the Hop Limit”.
> 
> Unsure: The Hop Limit is a field that can be compressed at the first hop and 
> will need to be expanded later.
> 
> 
> Many thanks for your care, Peter. I looked up and fixed other occurrences of 
> the similar French and I hope the doc reads better now. 
> 
> If you agree with the points above I'll submit a new round asap, maybe 
> together with another review.
> 
> All the best,
> 
> Pascal
> 
> ___
> 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] [6lo] Genart last call review of draft-ietf-6lo-minimal-fragment-08

[Alissa Cooper]

Francesca, thanks for your review. Pascal, thanks for your response. I entered 
a No Objection ballot.

Best,
Alissa


> On Feb 3, 2020, at 2:40 AM, Francesca Palombini 
>  wrote:
> 
> Looks good Pascal. Thanks for your quick update!
> 
> Francesca
> 
> On 31/01/2020, 10:55, "Pascal Thubert (pthubert)"  wrote:
> 
>Hello Francesca:
> 
>Many thanks for your review : )
> 
> 
>> Summary: This draft is basically ready for publication. However, I noticed 
>> the
>> normative reference to an informative document, draft-ietf-lwig-6lowpan-
>> virtual-reassembly (ref. 'LWIG-VRB'), which is problematic, since this draft 
>> is
>> on the standard track.
> 
>Moved both this and the reference to recoverable frags to informational. 
> They are just illustrative anyway.
> 
>> 
>> Major issues: -
>> 
>> Minor issues: -
>> 
>> Nits/editorial comments:
>> 
>> * Last paragraph of Section 5, I suggest a minor reformulation for clarity.
>> 
>> OLD:
>>   An associated
>>   caveat is that on a half duplex radio, if node A sends the next
>>   fragment at the same time as node B forwards the previous fragment to
>>   a node C down the path then node B will miss the next fragment.
>> NEW:
>>   An associated
>>   caveat is that on a half duplex radio, if node A sends the next
>>   fragment at the same time as node B forwards the previous fragment to
>>   a node C down the path then node B will miss the next fragment from node
>> A.
>> 
> 
>Applied, and published 09. Please let me know if we are all set now? 
> 
> 
>Again, many thanks, Francesca!
> 
>Pascal
> 
> 
> ___
> 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-6lo-backbone-router-14

[Alissa Cooper]

Elwyn, thanks for your review. Pascal, thanks for your responses. I entered a 
No Objection ballot.

Alissa


> On Feb 7, 2020, at 2:54 PM, Pascal Thubert (pthubert)  
> wrote:
> 
> Hello Elwyn
> 
> I implemented it on Cisco IOS years ago. What really hurts is the delay 
> between that and the spec being finalized. The gory details of what I had to 
> do escape me now but at least I still have the code as reference.
> 
> Many thanks again !
> 
> Pascal
> 
>> Le 7 févr. 2020 à 20:47, elwynd  a écrit :
>> 
>> 
>> Hi, Pascal.
>> 
>> Thanks for the rapid turnround!
>> 
>> I did check the abbreviations list for the well-knownness of MAC.  There are 
>> a multitude of possible expansions so it is not marked as well-known.
>> 
>> But otherwise... that looks good and we are all done.
>> 
>> It is pretty complex system and I can't say that my brain was capable of 
>> running a proper simulation ;-) but it seemed to cover most of the bases 
>> that I could think of.  Are there existing implementations (I'd guess so!) - 
>> if so it might be worth mentioning somethng about them but that is a 
>> nice-to-have.
>> 
>> Cheers,
>> Elwyn
>> 
>> 
>> 
>> Sent from Samsung tablet.
>> 
>> 
>>  Original message 
>> From: "Pascal Thubert (pthubert)" 
>> Date: 07/02/2020 13:36 (GMT+00:00)
>> To: Elwyn Davies , gen-art@ietf.org
>> Cc: last-c...@ietf.org, draft-ietf-6lo-backbone-router@ietf.org, 
>> 6...@ietf.org
>> Subject: RE: Genart last call review of draft-ietf-6lo-backbone-router-14
>> 
>> Hello Elwyn:
>> 
>> Many thanks for your review!
>> 
>> Let's see below:
>> 
>> 
>> > General: s/i.e. /i.e., / (4 places), s/e.g. /e.g.,/ (2 places)
>> 
>> Done
>> 
>> > 
>> > Abbreviations: The definition of abbreviations in this document is 
>> > inconistent.
>> > There is a list of abbreviations but it is not complete; many 
>> > abbreviations are
>> > introduced in the text in the usual way and there are some that are not
>> > expanded. Please be consistent - a complete list would be helpful, 
>> > especially
>> > as some are used before the abbreviations section.
>> 
>> Made a pass
>> 
>> 
>> > References to Neighbor Solicitation/Advertisement messages: The formats
>> > NS() and NA() are used to refer to various NS/NA messages. Please
>> > add an explanation of this convention and a definition of the various
>> > messages referred to.
>> 
>> Added the abbreviations
>> 
>> 
>> > Use of Layer-2 and Layer-3:  These terms are not normally  hyphenated.
>> 
>> Removed the hyphen.
>> 
>> > s1: Term STA used for a 'node': Please expand this abbreviation and 
>> > possibly
>> > explain why it is used (I am unclear how it is derived).
>> 
>> STA and AP are 802.11 terminology,  STA means station I believe. Changed to 
>> "
>> connectivity to the end node (the Wi-Fi STA)
>> "
>> 
>> > 
>> > s1, para 5: s/Like/In the same way as/
>> 
>> Done
>> 
>> > 
>> > s1, para 5: ID is not a well-known abbreviation - please expand on first 
>> > use.
>> 
>> Added in the "Abbreviation" section which is where it is first used
>> 
>> > 
>> > s1, para 9: Need to expand MAC.
>> 
>> I think we got directives from RFC editor not to expand very well-known 
>> terms. If my memory serves me that was one.
>> 
>> > 
>> > s2.2, "Sleeping Proxy": It might be useful to add in " which might be in a 
>> > sleep
>> > state in a low power network".
>> 
>> "
>>Sleeping Proxy
>> 
>>  A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor
>>  Solicitations over the Backbone on behalf of the Registering
>>  Node which might be in a sleep state in a low power network.
>>  The Sleeping Proxy that is also a Bridging Proxy will
>>  preferably forward the relevant messages to the Registering
>>  Node as unicast frames in accord to the duty cycle of the
>>  Registering Node and let it respond.
>> 
>> 
>> "
>> 
>> > 
>> > s2.2, "Routing Proxy": Need to expand TLLA.
>> 
>> Done
>> 
>> > 
>> > s3, para 1: s/The next/The following/ 
>> 
>> Done
>> 
>> > 
>> > s3, 2nd set of bullets, bullet #2: s/This includes participating to the
>> >   solicited-node multicast address/This includes responding to messages
>> >   addressed tothe solicited-node multicast address/
>> 
>> The point is really the MLD thingy. What about:
>> 
>> "
>>  This includes joining the multicast group associated to
>>   the SNMA derived from the Registered Address as specified in
>>   section 7.2.1. of [RFC4861] over the Backbone.
>> 
>> "
>> 
>> > 
>> > s3, 2nd set of bullets, bullet #3: Expand NUD on first use (currently 
>> > expanded
>> > twice in sss6 and 8).
>> 
>> Done and looked up /updated the other cases
>> 
>> > s3.1: Expand SLLAO on first use.
>> 
>> done
>> 
>> > s3.3, para at bottom of page 13 just before Figure 5: s/is a transmitted 
>> > as a
>> > multicast/is transmitted as a multicast /
>> 
>> done
>> 
>> > s3.3, last para: s/suggests using RPL/suggests using the RPL routing 
>> > protocol/
>> 
>

Re: [Gen-art] [core] Genart last call review of draft-ietf-core-senml-more-units-02

[Alissa Cooper]

Linda, thanks for your review. Carsten, thanks for your response. I entered a 
DISCUSS ballot to ask some questions about interoperability.

Best,
Alissa


> On Oct 31, 2019, at 1:21 PM, Carsten Bormann  wrote:
> 
> Hi Linda,
> 
> thank you for this review.
> 
>> On Oct 31, 2019, at 17:41, Linda Dunbar via Datatracker  
>> 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 treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> .
>> 
>> Document: draft-ietf-core-senml-more-units-??
>> Reviewer: Linda Dunbar
>> Review Date: 2019-10-31
>> IETF LC End Date: 2019-10-30
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary:  The document is very light, describing IANA registration for 
>> acronyms
>> for various UNITs, such as "ms" for Millisecond, "min" for Minute, "kW" for
>> Kilowatt, etc. While there is no problem of those acronyms, I don't really
>> understand why it is necessary to have an RFC for this purpose. Many IETF 
>> areas
>> don’t even allow Gap Analysis drafts to be published as RFCs.
> 
> Registrations to an existing registry indeed do not require an RFC.
> 
> However, beyond registering a few values, this draft also
> 
> — creates a new registry and defines its expert review instructions,
> — updates Standards Track RFC 8428 to accept values from this registry in a 
> place previously governed only by a different registry.
> 
> While there is still some ongoing debate about whether this was the right 
> approach to address the requirements, if we uphold this approach we will 
> require an RFC.
> 
> Grüße, Carsten
> 
> ___
> 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-mpls-summary-frr-rsvpte-07

[Alissa Cooper]

Theresa, thanks for your review. Tarek, thanks for addressing Theresa’s 
comments. I entered a No Objection ballot.

Alissa


> On Feb 11, 2020, at 2:57 PM, Tarek Saad  wrote:
> 
> Hi Theresa,
> 
> Thanks again for your feedback and confirmation.
> The document has been scheduled for a telechat. I accept your suggestion, and 
> I'll hold your comment for the next update of the document.
> 
> Regards,
> Tarek
> 
> On 2/11/20, 12:23 PM, "Theresa Enghardt"  wrote:
> 
>Hi Tarek,
> 
>Thanks for the replies and the new revision, and sorry for the late
>response.
> 
>Your recent revision addresses most of my comments.
> 
>Please find one further comment below:
> 
>On 29.12.19 20:38, Tarek Saad wrote:
>> […]
>>3.3
>>"the PLR MUST ensure bypass tunnel assignment can satisfy the protected 
>> LSP MTU
>>requirements post FRR" - Is there an existing mechanism to do this?
>> [TS]: Section 2.6 in RFC3209 describes a mechanism to determine whether a 
>> node should fragment or drop a packet that exceeds the Path MTU as 
>> discovered using RSVP signaling on primary LSP path. A PLR can leverage the 
>> RSVP discovered Path MTU on the backup and primary LSP path to ensure MTU is 
>> not exceeded after rerouting traffic on to the bypass tunnel.
> 
>I think it'd be helpful to add a reference to that RFC and section here.
> 
>Best,
>Theresa
> 
> ___
> 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