Re: [Gen-art] Gen-ART review of draft-ietf-isis-rfc6326bis-01

[Alexey Melnikov <[e-mail]>]

Hi Donald,

On 20/01/2014 16:45, Donald Eastlake wrote:
> Hi Alexey,
>
> Thanks for your review, see below:
>
> On Mon, Jan 20, 2014 at 6:12 AM, Alexey Melnikov
> <[e-mail]> wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Please resolve these comments along with any other Last Call
>> comments you may receive.
>>
>> Document: draft-ietf-isis-rfc6326bis-01
>> Reviewer: Alexey Melnikov
>> Review Date: 2014-01-20
>> IETF LC End Date: 2014-01-22
>> IESG Telechat date: 2014-01-23
>>
>>
>> Summary: This draft is nearly ready for publication as a standard track RFC.
>>
>> Major issues: None
>>
>> Minor issues:
>>
>> o  Label: This carries the fine-grained label identifier for all
>>        subsequent MAC addresses in this sub-TLV, or the value zero if no
>>        label is specified.
>>
>> I fully admit ignorance of the topic, but what is exactly
>> "fine-grained label" and where is the exact format defined? If it is
>> defined later in the document, can you please add a forward
>> reference. If it is defined in another document, can you please add
>> a reference to that.
> Fine grained labels are specified in draft-ietf-trill-fine-labeling-07,
> which is an approved standard track draft in the RFC Editor's
> queue. Adding a reference to it here would be good.
Sounds great. Thanks.
>> In Sections 2.2.4 and 2.3.1:
>>
>> What are the requirements on backward compatibility between different
>> versions of TRILL. Are TLVs formats supported for a version N also valid for
>> version N+M? If you have any implied assumptions, please state them in the
>> document.
> There are no explicit requirements. Incremental changes and
> improvements are generally handed with capability bits or the
> presence/absence of data strucutres in control messages. A version
> change would probably indicate a pretty major modification but, since
> these version numbers are within IS-IS TLVs, I would say that
> implicitly the intent is to stay with the IS-IS PDU structure for the
> control plane.
I think the document should state that. Also, if you want any messages 
to be unchanged (fully or partially) irrespectively of version numbers, 
you should state that too.

Best Regards,
Alexey