Re: [Gen-art] [6lo] Genart last call review of draft-ietf-6lo-blemesh-08

[Alissa Cooper <[e-mail]>]

Pete, thanks for your review. Carles, thanks for making the updates. I entered a No Objection ballot.

Alissa


> On Dec 8, 2020, at 3:37 AM, Carles Gomez Montenegro <[e-mail]> wrote:
> 
> Hi Pete,
> 
> Thanks a lot for your review of the draft!
> 
> We just submitted -09, which aims at addressing the last round of review
> comments, including yours:
> https://tools.ietf.org/html/draft-ietf-6lo-blemesh-09 <https://tools.ietf.org/html/draft-ietf-6lo-blemesh-09>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-09 <https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-09>
> 
> Please find below our inline responses to your comments:
> 
>> 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
>> 
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>> 
>> Document: draft-ietf-6lo-blemesh-08
>> Reviewer: Pete Resnick
>> Review Date: 2020-12-04
>> IETF LC End Date: 2020-10-21
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary: Looks good to me, with two items that seemed confusing enough
>> that
>> they should be addressed.
>> 
>> Note that this review is being done well after the close of the Last Call.
>> Since this is not yet scheduled for a telechat, the AD asked that I go
>> ahead
>> and complete the review anyway.
>> 
>> Major issues: None
>> 
>> Minor issues:
>> 
>> 3.3.2, #4:
>> 
>>   Implementations of this specification MAY support
>>   the features described in sections 8.1 and 8.2 of RFC 6775, as
>>   updated by RFC 8505, unless some alternative ("substitute") from some
>>   other specification is supported by the implementation.
>> 
>> This bit confused me. I think it was the "unless". Do you mean it MAY
>> support
>> the 6775/8505 features, or MAY support some substitute, or MAY support
>> neither,
>> or do you mean that it MUST support either the 6775/8505 features or MUST
>> support some substitute? I think you want to rewrite this to make it clear
>> which one you mean.
> 
> Agreed. We modified the text as follows:
> 
> NEW:
>   Implementations of this specification MUST either
>   support the features described in sections 8.1 and 8.2 of RFC 6775,
>   as updated by RFC 8505, or some alternative ("substitute") mechanism.
> 
>> 3.3.3, last two paragraphs:
>> 
>>   When a 6LN transmits a packet, with a non-link-local source address
>>   that the 6LN has registered with EARO in the next-hop router for the
>>   indicated prefix, the source address MUST be fully elided if it is
>>   the latest address that the 6LN has registered for the indicated
>>   prefix (SAC=1, SAM=11).  If the source non-link-local address is not
>>   the latest registered by the 6LN, then the 64 bits of the IID SHALL
>>   be fully carried in-line (SAC=1, SAM=01) or if the first 48 bits of
>>   the IID match with the latest address registered by the 6LN, then the
>>   last 16 bits of the IID SHALL be carried in-line (SAC=1, SAM=10).
>> 
>>   When a router transmits a packet to a neighboring 6LN, with a non-
>>   link-local destination address, the router MUST fully elide the
>>   destination IPv6 address if the destination address is the latest
>>   registered by the 6LN with EARO for the indicated context (DAC=1,
>>   DAM=11).  If the destination address is a non-link-local address and
>>   not the latest registered, then the 6LN MUST either include the IID
>>   part fully in-line (DAM=01) or, if the first 48 bits of the IID match
>>   to the latest registered address, then elide those 48 bits (DAM=10).
>> 
>> Both of these were a bit confusing to me. I think you want to reverse the
>> order
>> of the last two choices. Say something like (for the first paragraph), "If
>> the
>> source non-link-local address is not the latest registered by the 6LN and
>> the
>> first 48 bits match..., then the last 16 bits SHALL be carried in-line.
>> Otherwise, if first 48 bits do not match, then the 64 bits shall be
>> carried
>> inline." Similarly for the second. As it is, it takes a while to figure
>> out
>> what it means.
> 
> We modified the two paragraphs as per your suggestion.
> 
>> Nits/editorial comments: Do fix the reference nits noted by the nits tool;
>> they
>> appear to be simple typos.
> 
> Done!
> 
> Cheers,
> 
> Carles (on behalf of the authors)
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>