Re: [mpls] Closing on draft-ietf-mpls-mna-requirements adoption poll comments

["Dongjie (Jimmy)" <[e-mail]>]

Hi Matthew,

Thanks for your reply, I look forward to the updates in next revision.

Best regards,
Jie

From: Bocci, Matthew (Nokia - GB) [mailto:[e-mail]]
Sent: Friday, August 19, 2022 9:58 PM
To: Dongjie (Jimmy) <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [mpls] Closing on draft-ietf-mpls-mna-requirements adoption poll comments

Adrian, Jimmy

Thanks for your additional comments. I have just posted an update that is intended to address the discussion regarding private use network actions. We have not yet had the opportunity to go through your comments but plan to do so shortly and will respond/address them in the next version.

Best regards

Matthew

From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 3 August 2022 at 11:04
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [mpls] Closing on draft-ietf-mpls-mna-requirements adoption poll comments
Hi authors, Adrian and WG,

Please find some additional response to the resolution of the comments in the appendix. Thanks.

Best regards,
Jie


> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Wednesday, July 27, 2022 6:14 AM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: [mpls] Closing on draft-ietf-mpls-mna-requirements adoption poll
> comments
>
> Hi authors,
>
> Thanks for your work in advancing this document and especially for collating
> the adoption poll comments in the Appendix.
>
> I agree that this Appendix can now be removed, but concurrent with that I
> thought it would be helpful to review your resolutions of the comments. It's
> not clear who raised which comments, but I'm considering them all here.
>
> Cheers,
> Adrian
>
> ===
>
>    2.   The NAS abbreviation
>
> [AF] OBE per 3

[Jie] This term is not used in the requirements, thus the change in abbreviation is out of scope of this document

>
>    3.   non-use of NAS abbreviation
>
> [AF] OK with resolution

[Jie] Agree to remove NAS from this document.

>    7.   ADI -> NAI
>
> [AF] OK with resolution

[Jie] I don't think this is fully solved. The replacement of ADI with NAI has caused the problem of mixing up the requirements on two different levels of indicators. It is good to see in the -02 version of the requirement draft, separate subsections (3.2 and 3.3) are newly created for the two levels of indicators, while the text in each subsection needs to be reviewed to make sure they align with the title of each subsection.

>
>    8.   Addition to section 3.1
>
>         For backward compatibility and consistency, It is suggested to
>         add the below items to section 3.1 as general requirements: a)
>         Solutions meeting the requirements set out in this document MUST
>         be compatible with existing MPLS mechanisms.  b) Solutions
>         meeting the requirements set out in this document MUST reuse
>         existing MPLS mechanisms when possible.  c) For network actions
>         which are developed or under development in IETF, the encoding
>         and processing of the network action data MUST be reused.
>
>         Ed.> Requirements 1-4 already cover points a and b.  C is
>         outside the scope of this document but we are not intending to
>         limit or prescribe anything about existing standards.

> [AF] I disagree that 3.1#1 is related to backward compatibility. It talks about
> how the resultant solution must enable the functions currently available in
> MPLS: that is not backward compatibility.
> [AF] I disagree that 3.1#2 is about backward compatibility. It talks about how
> the resultant architecture must remain generally applicable, but it does not
> talk about backward compatibility.
> [AF] I disagree that 3.1#3 is about backward compatibility. It talks about
> extensions not being incompatible with the architecture, but it does not imply
> backward compatibility.
> [AF] Item 3.1#4 might be interpreted as being about backward compatibility,
> but it is not quite clear that "coexist with" and "not obsolete" actually means
> backward compatibility. That may be the authors' intention, but backward
> compatibility would also mean that a legacy implementation encountering a
> solution to these requirements must not have an undesired response or there
> must be a way to prevent such an implementation seeing such an encounter.
>
> [AF] However, 3.3#2 and 3.3#3 do seem to cover this. So no further action