Re: [Lsr] Pre-writeup review comments

Just to confirm, yes, that change Peter has made removing END.T resolves 
my concerns.
Thanks,
Joel

On 10/8/2020 9:38 AM, Peter Psenak wrote:
> Hi Chris,
> 
> please see inline:
> 
> On 02/10/2020 12:32, Christian Hoppsprotocol= application/pgp-signature 
> wrote:
>> Thanks for the update, a couple issues remain.
>>
>> [ ] 7.1 and 8.1
>>
>> The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are
>> defined differently (and probably incorrectly) than the other reserved 
>> bits.
>> Reserved bits "MUST" be set to zero, not "SHOULD", I believe.
> 
> fixed.
> 
>>
>> [ ] 11.  Implementation Status
>>
>> I know you mentioned that the section should be removed, but how about 
>> adding a note to the editor in the next revision e.g., "RFC Ed.: 
>> Please remove this section prior to publication"?
> 
> done
> 
>>
>> [ ] 12.5.  Sub-Sub-TLVs for SID Sub-TLVs
>>
>> This section needs to better conform to registry creation standards (see
>> https://tools.ietf.org/html/rfc8126). In particular there is no guidance.
> 
> I have modified the section 12.5.
> 
> 
>>
>> It looks like there is more discussion from Joel on this draft, so I 
>> will hold off on submission for that to resolve.
> 
> I have removed the END.T in the latest version. The discussion with Joel 
> is closed.
> 
> thanks,
> Peter
> 
>>
>> Thanks,
>> Chris.
>>
>>> On Sep 23, 2020, at 4:36 PM, Peter Psenak 
>>> <ppsenak=40cisco.com@dmarc.ietf.org> wrote:
>>>
>>> Hi Chris,
>>>
>>> thanks for your comments.
>>>
>>> Please see inline (##PP):
>>>
>>> On 18/09/2020 16:08, Christian Hoppsprotocol= 
>>> application/pgp-signature wrote:
>>>> During my review and while doing the Shepherd writeup for 
>>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I 
>>>> came up with the following comments:
>>>> 4.3 - Maximum H.Encaps MSD Type:
>>>>    - what is the default if not advertised?
>>>
>>> ##PP
>>> added "or no value is advertised" as for other MSD types.
>>>
>>>> 6.  Advertising Anycast Property
>>>> Should "Locator that is advertised..." be:
>>>>    "An SRv6 Locator that is advertised..."?
>>>> or:
>>>>    "A prefix/SRv6 Locator that is advertised..."?
>>>
>>> ##PP
>>> fixed.
>>>
>>>> 7.1 SRv6 Locator TLV Format
>>>> The R fields and their handling, are not defined.
>>>
>>> ##PP
>>> added
>>>
>>>
>>>> 8.  Advertising SRv6 Adjacency SIDs
>>>> "must be" "in order to be correctly applied" -> "are" and ""?
>>>
>>> ##PP
>>> I replaced with:
>>>
>>> Certain SRv6 Endpoint behaviors 
>>> [I-D.ietf-spring-srv6-network-programming] are associated with a 
>>> particular adjacency.
>>>
>>>
>>>> 8.1.  SRv6 End.X SID sub-TLV
>>>> "Other bits" -> "Reserved bits" -- labels should match
>>>
>>> ##PP
>>> fixed.
>>>
>>>> 8.2.  SRv6 LAN End.X SID sub-TLV
>>>> I'm sympathetic to Bruno's comment, and so I think it would be 
>>>> better to say:
>>>> Diagram: "System ID (1-6 octets)" and in text:
>>>> "6 octets" -> "System ID: 1-6 octets"
>>>> I see no reason to mess with this even if the commonly-implemented 
>>>> value is 6 at
>>>> this point. IS-IS implementations that only support 6 octets are 
>>>> free to only
>>>> support 6 in this sub-TLV as well. They won't be talking with other 
>>>> IS-IS
>>>> routers that are configured to have a non-6 octet system ID value. 
>>>> What other
>>>> extension RFCs may or may-not do WRT this doesn't really matter I 
>>>> think.
>>>
>>> ##PP
>>> I have updated the text to match what is being used in RFC8667, 
>>> section 2.2.2
>>>
>>>
>>>> "Other bits" -> "Reserved bits" -- labels should match
>>>
>>> ##PP
>>> fixed
>>>
>>>> 11.  Implementation Status
>>>> Does this section need a "RFC Ed.: Please Remove prior to 
>>>> publications"? It
>>>> seems pretty wrong to document current status of implementations 
>>>> permanently in
>>>> an Standards Track RFC.
>>>
>>> ##PP
>>> yes this section will be removed prior to publication. This is a 
>>> standard procedure we follow.
>>>
>>>> 12. IANA Considerations
>>>> An odd space between "sub- TLV".
>>>
>>> ##PP
>>> fixed
>>>
>>>> 12.5.  Sub-Sub-TLVs for SID Sub-TLVs
>>>> This section needs to better conform to registry creation standards 
>>>> (see
>>>> https://tools.ietf.org/html/rfc8126).
>>>
>>> ##PP
>>> I updated the IANA section format similar to RFC8667.
>>>
>>>
>>>> ID-NITS:
>>>>    There are 19 instances of too long lines in the document, the 
>>>> longest one
>>>>    being 5 characters in excess of 72.
>>>
>>> ##PP
>>> fixed.
>>>
>>>> References:
>>>>    Normative:
>>>>      Published: RFC 8754 draft-6man-segment-routing-header
>>>
>>> ##PP
>>> fixed.
>>>
>>>
>>>>      Out of date reference: [I-D.ietf-6man-spring-srv6-oam]
>>>>      Out of date reference: [I-D.ietf-spring-srv6-network-programming]
>>>
>>> ##PP
>>> Whenever the new version of draft-ietf-lsr-isis-srv6-extension is 
>>> published it picks the latest version, but as these drafts keep 
>>> changing the reference may get out of date quickly.
>>>
>>>
>>>
>>>>    Informative:
>>>>      Published: RFC 8402 draft-ietf-spring-segment-routing
>>>
>>> ##PP
>>> fixed
>>>
>>> thanks,
>>> Peter
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>
>>
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr