Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Hi Mark,



Thank you for your comment.

As you have pointed out, currently in Section 3.1 we have the following text:



A locator may be represented as B:N where B is the SRv6 SID block

(IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the

      identifier of the parent node instantiating the SID.



This is exactly like any IPv6 address allocation to a router as part of a subnet of a domain.



Thanks,

Pablo.



-----Original Message-----

From: Mark Smith <[e-mail]>

Date: Monday, 2 March 2020 at 22:48

To: Martin Vigoureux <[e-mail]>

Cc: SPRING WG <[e-mail]>, 6MAN <[e-mail]>, draft-ietf-spring-srv6-network-programming <[e-mail]>

Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Resent from: <[e-mail]>

Resent to: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

Resent date: Monday, 2 March 2020 at 22:48



    On Tue, 3 Mar 2020 at 08:39, Mark Smith <[e-mail]> wrote:

    >

    > This -11 draft was posted at 3:53 am Melbourne, Australia time, and this declaration of consensus was at 5:35 am Melbourne, Australia time.

    >

    > Sometimes I'm awake at those hours, but not last night. I did not have an opportunity to review the changes.

    >



    Reviewing what was changed, my comment section 3.1, "SID Format", and

    offer to provide some text as been completely ignored.



    "[spring] draft-ietf-spring-srv6-network-programming-10 - "3.1. SID

    Format" should be more prescriptive"



    https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf7k/



    Regards,

    Mark.







    >

    > Regards,

    > Mark.

    >

    >

    >

    >

    > On Tue, 3 Mar 2020, 05:53 Martin Vigoureux, <[e-mail]> wrote:

    >>

    >> WG,

    >>

    >> as I had indicated in a previous message I am the one evaluating

    >> consensus for this WG LC.

    >>

    >> I have carefully read the discussions on the list. I acknowledge that

    >> disagreements were expressed regarding what a particular piece of text

    >> of RFC 8200 says, and on which this document builds to propose an

    >> optional capability. Since RFC 8200 is not a product of the SPRING WG, I

    >> have paid specific attention to the messages ([1], [2], and [3]) sent by

    >> the responsible AD of 6MAN and of RFC8200.

    >>

    >> My overall conclusion is that there is support and rough consensus to

    >> move this document to the next stage.

    >>

    >> Bruno will handle the immediate next steps.

    >>

    >>

    >> Martin

    >>

    >>

    >> [1]

    >> https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/

    >> [2]

    >> https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/

    >> [3]

    >> https://mailarchive.ietf.org/arch/msg/spring/uBYpxPyyBY6bb86Y2iCh3jSIKBc/

    >>

    >> Le 2019-12-05 à 18:15, [e-mail] a écrit :

    >> > Hello SPRING,

    >> >

    >> > This email starts a two weeks Working Group Last Call on

    >> > draft-ietf-spring-srv6-network-programming [1].

    >> >

    >> > Please read this document if you haven't read the most recent version,

    >> > and send your comments to the SPRING WG list, no later than December 20.

    >> >

    >> > You may copy the 6MAN WG for IPv6 related comment, but consider not

    >> > duplicating emails on the 6MAN mailing list for the comments which are

    >> > only spring specifics.

    >> >

    >> > If you are raising a point which you expect will be specifically debated

    >> > on the mailing list, consider using a specific email/thread for this point.

    >> >

    >> > This may help avoiding that the thread become specific to this point and

    >> > that other points get forgotten (or that the thread get converted into

    >> > parallel independent discussions)

    >> >

    >> > Thank you,

    >> >

    >> > Bruno

    >> >

    >> > [1]

    >> > https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

    >> >

    >> > _________________________________________________________________________________________________________________________

    >> >

    >> > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

    >> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

    >> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

    >> > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

    >> >

    >> > This message and its attachments may contain confidential or privileged information that may be protected by law;

    >> > they should not be distributed, used or copied without authorisation.

    >> > If you have received this email in error, please notify the sender and delete this message and its attachments.

    >> > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

    >> > Thank you.

    >> >

    >> >

    >> >

    >> > _______________________________________________

    >> > spring mailing list

    >> > [e-mail]

    >> > https://www.ietf.org/mailman/listinfo/spring

    >> >

    >>

    >> _______________________________________________

    >> spring mailing list

    >> [e-mail]

    >> https://www.ietf.org/mailman/listinfo/spring