Re: [spring] Working Group Adoption Call for draft-filsfils-spring-srv6-network-programming

["Adrian Farrel" <[e-mail]>]

Thanks for this poll, Bruno,

 

Before taking up work on this draft, would it be worth working with 6man to
check that the repurposing of IPv6 addresses would be unlikely to cause a
great fight? It would probably be better to not have two WGs fighting.

 

And, in case someone is confused by my comments, RFC 4291 has.

 

   IPv6 addresses are 128-bit identifiers for interfaces and sets of

   interfaces (where "interface" is as defined in Section 2 of [IPV6]).

 

And RFC 8200 has.

 

      interface    a node's attachment to a link.

 

and

 

      Destination Address 128-bit address of the intended recipient of

                          the packet (possibly not the ultimate

                          recipient, if a Routing header is present).

                          See [RFC4291] and Section 4.4.

 

Now, it is possible that everyone will say "Yeah, go ahead." Or they may
say, "You can only do this if you're also updating 4291 and 8200." Or, of
course, they may also say, "Whoa, it would be a really big step to address a
function or an instruction or something other than an interface,
notwithstanding that they are routable."

 

I'm not prejudging what answer we might get, but think it would be worth
asking.

 

Best,

Adrian

 

 

From: spring <[e-mail]> On Behalf Of
[e-mail]
Sent: 13 March 2019 18:50
To: SPRING WG <[e-mail]>
Cc: [e-mail]
Subject: [spring] Working Group Adoption Call for
draft-filsfils-spring-srv6-network-programming

 

Hi SPRING WG,
 
This email initiates a three week call for working group adoption for
draft-filsfils-spring-srv6-network-programming. (Three weeks to account for
the IETF week)
 
Please indicate your support, comments, or objection, for adopting this
draft as a working group item by April, 3rd, 2019 (aka 2019-04-03)
We are particularly interested in hearing from working group members that
are not co-authors of this draft.
 
We are also looking for volunteers who would be ready to perform a technical
review of this work at some later stage, such as before or during WG the
last call.
 
In parallel to this adoption call, I will send an IPR call for this
document. We will need all authors and contributors to confirm their IPR
position on this document.
There is currently 1 IPR filled (2)
 
(1)
https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-0
7
(2)
https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-netwo
rk-programming
<https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-netw
ork-programming&submit=draft> &submit=draft
 
 
Thank you,
--Bruno & Rob.

 

____________________________________________________________________________
_____________________________________________
 
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.