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 <[email protected]>
Date: Monday, 2 March 2020 at 22:48
To: Martin Vigoureux <[email protected]>
Cc: SPRING WG <[email protected]>, 6MAN <[email protected]>,
draft-ietf-spring-srv6-network-programming
<[email protected]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email protected]>
Resent to: <[email protected]>, <[email protected]>, <[email protected]>,
<[email protected]>, <[email protected]>,
<[email protected]>
Resent date: Monday, 2 March 2020 at 22:48
On Tue, 3 Mar 2020 at 08:39, Mark Smith <[email protected]> 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, <[email protected]>
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, [email protected] 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
>> > [email protected]
>> > https://www.ietf.org/mailman/listinfo/spring
>> >
>>
>> _______________________________________________
>> spring mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
