Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)

["Joel M. Halpern" <[e-mail]>]

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" <[e-mail]>
>> 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.
>>
>>
>>
>>