Magnus, while it is possible we will still get hold ups on the LISP
documents, I would really prefer to avoid creating a normative
dependency on something that at best is 6 months away. Particularly
since the TSVWG has not cared enough to maintain the document.
Yours,
Joel
On 7/9/2020 1:50 PM, Magnus Westerlund wrote:
Hi,
No, RFC 3819 is not a good replacement for the draft. I would note that only a
minor part of RFC 3819 is updated by draft-ietf-tsvwg-ecn-encap-guidelines.
So I contacted the TSVWG chairs to try to get an update on when the document
could be ready. The WG has not abandonded it. Actually I found an updated
version from March that simply failed to make it into the public archive at that
point.
I will also note that the document has gone through one WG last call and appear
to be in descent shape. The only issue is that the main author been busy with
L4S that is a hot topic in TSVWG.
We have requested an estimate for an update from Bob Briscoe so that we can get
this document going forward.
So it might be possible to get this document approved before the end of the
year.
As an alternativ there might be possible that you can reformulate the sentence
so that the high level requirement that the reader is expected to derive is
expressed in your document, and then you can get to a state where the reference
would only be informative?
Cheers
Magnus
On Thu, 2020-07-09 at 16:51 +0000, Fabio Maino (fmaino) wrote:
Hi Magnus, thanks for your comments.
Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the draft is
expired, so making it normative might not be an option.
Since it is meant to replace RFC3819, should we refer to RFC3819 instead?
Thanks,
Fabio
On 7/9/20, 5:43 AM, "Magnus Westerlund via Datatracker" <[email protected]>
wrote:
Magnus Westerlund has entered the following ballot position for
draft-ietf-lisp-gpe-17: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Section 4.2:
To me it looks like this is normative reference:
Such new encapsulated payloads, when registered with LISP-
GPE, MUST be accompanied by a set of guidelines derived from
[I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
Section 4.3.1:
Thanks for writing relevant guidance on how to mitigate the risks with
zero
checksum. Especially the one on traffic separation from other traffic so
that
it can be caught on the boundaries of the network to prevent the risk to
other
networks from corrupted traffic.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
