Hi chairs,
I hate to sound like a broken record. I just want to get this issue
clarified before we get to a late stage and risk being forced to start
again.
RFC 8200 defers to RFC 4291 for the definition of an IPv6 address. RFC 4291
has a somewhat simplistic and possibly historic definition of an IPv6
address.
IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces (where "interface" is as defined in Section 2 of [IPV6]).
..where the reference was to RFC 2460 which (of course) is obsoleted by RFC
8200. RFC 8200 has.
interface a node's attachment to a link.
address an IPv6-layer identifier for an interface or a set of
interfaces.
Now, during the adoption poll, I suggested that the chairs might like to
ping 6man to check that the proposed work in this draft is an acceptable
modification to this definition.
The challenge, as far as I see it, is purely semantic. That is, we propose
to place in the DA field of an IPv6 header a value which is routable but
which does not identify an interface.
I am not clear whether this represents an Update to RFC 8200 or to RFC 4291,
but I do strongly recommend that the chairs check with 6man that this
approach is not going to be rejected during IETF last call.
Thanks,
Adrian
From: spring <[email protected]> On Behalf Of
[email protected]
Sent: 24 April 2019 13:13
To: SPRING WG <[email protected]>;
[email protected]
Subject: Re: [spring] Working Group Adoption Call for
draft-filsfils-spring-srv6-network-programming
Hi authors, WG,
This document has been accepted as a new WG document.
Authors, please:
* update email address of authors
* republish current/same draft (reviewed and accepted by the WG) as
draft-ietf-spring-srv6-network-programming-00
* publish -01 to reflect comments and agreement made on the mailing
list
* reply to unanswered WG comments and engage resolution on open points
raised so far, in particular during WG adoption call. E.g. (1), (2)
As an additional point, this document is not intended to update RFC 8200. If
a behavior needs to update RFC 8200, it should be defined in a 6MAN draft in
the 6MAN WG and normatively referenced.
Thank you,
--Bruno, Rob
1.
https://mailarchive.ietf.org/arch/msg/spring/ulYVHKfb6h4fOtM8kqLmeGnVNlY
2.
https://mailarchive.ietf.org/arch/msg/spring/G_1ZqvInpZ9N2TX7TK8zOLa-e9I
From: spring [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, March 13, 2019 7:50 PM
To: SPRING WG
Cc: [email protected]
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-
07>
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-netw
ork-programming&submit=draft>
https://datatracker.ietf.org/ipr/search/?id=draft-filsfils-spring-srv6-netwo
rk-programming&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.
____________________________________________________________________________
_____________________________________________
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
