[mpls] Re: John Scudder's No Objection on draft-ietf-mpls-rfc6374-sr-16: (with COMMENT)

[Rakesh Gandhi <[e-mail]>]

Thank you John for the review comments and suggestions.

We have posted revision 17 with the suggested changes.

URL:      https://www.ietf.org/archive/id/draft-ietf-mpls-rfc6374-sr-17.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-sr/
HTML:     https://www.ietf.org/archive/id/draft-ietf-mpls-rfc6374-sr-17.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-mpls-rfc6374-sr
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-rfc6374-sr-17


Please see replies inline with <RG>...


On Thu, Oct 17, 2024 at 9:43 AM John Scudder via Datatracker <
[e-mail]> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-mpls-rfc6374-sr-16: No Objection
>
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-sr/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this well-written document. I have a few small comments.
>

<RG> Thanks.


>
> ### Section 2.3
>
>    The channel may be a directly connected link enabled with MPLS
>    (Section 2.9.1 of [RFC6374]) or a Point-to-Point (P2P) SR-MPLS path
>    [RFC8402].  The link may be a physical interface, a virtual link, or
>
> I don't see either "point-to-point" or "p2p" in RFC 8402. Would the quoted
> section be just as valid if you removed these adjectives?
>


<RG> Removed the adjective.



>
> ### Section 4.1.2
>
>    by the intended responder, the Destination Address TLV (Type 129)
>    [RFC6374] containing the address of the responder can be sent in the
>
> Shouldn't that be "an address of the responder" since in general it will
> have
> more than one?
>

<RG> Fixed.


>
> ### Section 9
>
>    responder.  If the responder does not support the new Mandatory TLV
>    Types defined in this document; it MUST return Error 0x17:
>    Unsupported Mandatory TLV Object as per [RFC6374].
>
> That seems like a misuse of the RFC 2119 keyword; by definition, this spec
> can't dictate any requirements to a responder that doesn't implement this
> spec.
> Probably you mean something like,
>
> NEW:
>    responder.  If the responder does not support the new Mandatory TLV
>    Types defined in this document it will return Error 0x17:
>    Unsupported Mandatory TLV Object as per [RFC6374].
>
> (I also removed a spurious semicolon.)
>
>
<RG> Fixed.

Many thanks,
Rakesh




>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>