>>> Still, using IID == 0 seems to be asking for trouble, since it's a
> reserved value and is definitely special-cased in some code. Unless, that
> is, you want exactly the properties described in RFC4291 section 2.6.1
> (thanks, Mark Smith).
>>
>> As Michael described, this assignment to
Ron,
[changed subject, as this seems of little relevance]
> So that I will know whether I am allowed to reply.
Wearing a chair's hat has never stopped anyone from replying before.
For formal 6man communication Bob and I generally sign with "Best regards, Bob
and Ole, 6man co-chairs".
Unless
Sander,
>> Your below list looks like custom made set of RFP requirements to eliminate
>> any other vendor or any other solution to solve the problem at hand rather
>> then rational list of requirements.
>
> My main customer (an ISP in NL) would fit exactly in the list that Ron sent.
> They
IP addresses have been used outside of the strict "identifiers for interfaces".
Apart from being used for routing, as a locator and as an identifier of course.
Load-balancers / addresses for a service, NAT, NPT66, NAT66, MAP-E/T, anycast
addresses...
I am sure there are plenty others.
Unless
Hi Ron,
Thank you, the last call for this document will stay open until the issues
raised are closed.
Currently we are awaiting a new revision from the authors. I expect a few more
rounds on this one.
Best regards,
Ole
> On 18 Dec 2019, at 22:07, Ron Bonica wrote:
>
> Ole,
>
> I have
> * polling the mailing list instead of deciding (on your own) that the
> group wants to work on EH insertion, and,
Which decision are you referring to?
I have certainly never decided that working group wants to work on header
insertion.
With regards to the documents, I believe I clarified the
Hi Ron,
> I am not quite sure how to take this email. Are you suggesting that we should
> review less, post less, and let the rubber stamping begin?
No, not at all. And if it was open for that interpretation I am sorry.
But there are a should's all of us could improve on.
- not repeat the same
Tom,
> Bear in mind that quality discussion is real work by those
> participating. It is a lot of effort to carefully read drafts, give
> clear feedback, and respond to rebuttals. I would like to think that
> the work individuals put in is justified by the outcome, and I assume
> it the chairs
Enno,
>>> comply with it. The onus is on them, not on us asking folks to comply
>>> with existing standards.
>>
>> Yes, we have heard your position on this now.
>> There is of course a lot more nuance to this argument.
>
> could you please explain said 'nuance' in more detail?
I could try,
>>> I would say that it seems we have not been following the processes that
>>> should be followed. This has happened repeatedly over time, for this
>>> very same topic. The process seems to be biased, and thus unfair to the
>>> rest of the wg participants.
>>
>> Which process are you talking
Fernando,
>>> Point taken. Could you comment on the current state of WG consensus?
>>
>> The working group session in Singapore ended with what appeared to be a view
>> that we should continue work on both documents (Mark's and the Voyer draft).
>> For the state of the wg consensus, I haven't
Ron,
> Point taken. Could you comment on the current state of WG consensus?
The working group session in Singapore ended with what appeared to be a view
that we should continue work on both documents (Mark's and the Voyer draft).
For the state of the wg consensus, I haven't checked with Bob,
Ron,
> Currently, there is no consensus that IPv6 allows insertion of extension
> headers by intermediate nodes, even if those intermediate nodes are segment
> endpoints . Given this lack of consensus, the authors of network programming
> have wisely agreed to remove header insertion from the
Tal,
> [Apologies if this issue has been discussed before.]
>
> According to draft-ietf-6man-segment-routing-header, an ‘SR Segment Endpoint
> Node’ updates the Destination IP address.
> Therefore, it must also update the Layer 4 Checksum, right?
>
> I wonder if there is an upper bound on the
14 matches
Mail list logo
