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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexey Melnikov-3
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.

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".

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.

What is "TAI"?

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".


_______________________________________________
mpls mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mpls
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Santosh Esale
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"
<[hidden email] on behalf of [hidden email]> 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
>[hidden email]
>https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mpls
Loading...