Re: [mpls] Alexey Melnikov's No Record on draft-ietf-mpls-app-aware-tldp-08: (with COMMENT)

[Santosh Esale <[e-mail]>]

Alexey,
       Thanks for the review. We have addressed most of your comments.


On 6/18/17, 1:58 PM, "mpls on behalf of Alexey Melnikov"
<[e-mail] on behalf of [e-mail]> wrote:

>Alexey Melnikov has entered the following ballot position for
>draft-ietf-mpls-app-aware-tldp-08: No Record
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>I have a small list of issues that I think you should look at:
>
>LSR -- needs expansion in the Abstract, as it is not an abbreviation
>recognized
>by RFC Editor.

Updated.
>
>In 2.2
>
>  If the receiver LSR does not receive the TAC TLV in the Initialization
>message
>  or it does not understand   the TAC TLV, the TAC negotiation MUST be
>  considered unsuccessful and the session establishment MUST proceed as
>per
>  [RFC5036].
>
>Firstly, you can't have requirements on any implementation that doesn't
>support
>this specification. Secondly, the last MUST is already the default. So I
>think
>use of RFC 2119 lange here is not appropriate, you should just use "is
>considered" and "proceeds".

Updated.
>
>The following text:
>
>If it sets the session setup retry interval to maximum, the session MAY
>stay in
>a non-existent state. When this LSR detects a change in the responding LSR
>configuration or its own configuration pertaining to TAC TLV, it MUST
>clear the
>session setup back off delay associated with the session in order to
>re-attempt
>the session establishment.

>is repeated twice in the same section.

The LSR playing the active role in LDP session establishment can be an
initiating 
LSR or a responding LSR. So some text is repeated to clearly specify the
procedures 
for initiating LSR and responding LSR.


>
>What is "TAI"?

It should be TA-Id. Updated.
>
>In 5.2: the section is titled "Use Cases", so I didn't expect any
>normative RFC
>2119 language in there. Some MAY seem not to be specifying implementation
>choices, so they should be "may".

Updated.


Santosh (On behalf of Authors)
>
>_______________________________________________
>mpls mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mpls