Subject: [manet] Question regarding RFC 8175 version 29

From: "Tran, Anthony" <[email-masked]>
Date: Tue, 7 Nov 2017 16:12:17 +0000

Hello,

I have a question regarding the scope of what RFC 8175 covers. Specifically section 13.8.1: IPv4 address processing.

   If the containing message is a Session Message, e.g., a Session
   Initialization Message (Section 12.5) or Session Update Message
   (Section 12.7), the receiver of inconsistent information MUST issue a
   Session Termination Message (Section 12.9) containing a Status Data
   Item (Section 13.1) with status code set to 130 'Invalid Data' and

   transition to the Session Termination state. Examples of such

   conditions are:

   o  An address Drop operation referencing an address that is not

      associated with the peer in the current session.

   o  An address Add operation referencing an address that has already

      been added to the peer in the current session.

Does the RFC cover what would be "invalid data" or is that determined by whoever is implementing the DLEP solution?

Thanks in advance,
Anthony Tran

Anthony Tran, E.I.T.
Evolve to Open (EvO) - Junior Software Engineer
General Dynamics Misson Systems Canada
[email-masked]<mailto:[email-masked]>
403-295-5251

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 7 Nov 2017 14:21:29 -0500

Anthony,

The two bulleted points you included from 13.8.1 cover some of the
"inconsistent data" that concerned us:

" ...Examples of such conditions are:

      been added to the peer in the current session."

That said, there is "wiggle room" in the text to allow implementations to
decide if additional conditions apply.

Regards,
Stan

On Tue, Nov 7, 2017 at 11:12 AM, Tran, Anthony <[email-masked]>
wrote:

> Hello,
>
> I have a question regarding the scope of what RFC 8175 covers.
> Specifically section 13.8.1: IPv4 address processing.
>
>
>
>    (Section 12.7), *the receiver of inconsistent information MUST issue a*
>
> *   Session Termination Message* (Section 12.9) containing a Status Data
>
> Does the RFC cover what would be “invalid data” or is that determined by
> whoever is implementing the DLEP solution?
>
> Thanks in advance,
>
> Anthony Tran
>
>
>
> *Anthony Tran, E.I.T.*
>
> Evolve to Open (EvO) – Junior Software Engineer
>
> [email-masked]
> 403-295-5251 <(403)%20295-5251>
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Rick Taylor <[email-masked]>
Date: Tue, 7 Nov 2017 21:09:43 +0000

Anthony,

Adding to Stan’s response, in my mind “inconsistent data” covered the case where there is nothing wrong with the format of the message, i.e. all the right bytes and concerning valid destinations, but the semantic content of the message indicated to one peer that the other peer had somehow got its internal information out of sync.  That was why the word “inconsistent” was picked.

Hope that helps?

Rick

From: manet [mailto:[email-masked]] On Behalf Of Stan Ratliff
Sent: 07 November 2017 19:21
To: Tran, Anthony
Cc: [email-masked]
Subject: Re: [manet] Question regarding RFC 8175 version 29

Anthony,

The two bulleted points you included from 13.8.1 cover some of the "inconsistent data" that concerned us:

That said, there is "wiggle room" in the text to allow implementations to decide if additional conditions apply.

Regards,
Stan

On Tue, Nov 7, 2017 at 11:12 AM, Tran, Anthony <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

   conditions are:

Does the RFC cover what would be “invalid data” or is that determined by whoever is implementing the DLEP solution?

Thanks in advance,
Anthony Tran

Anthony Tran, E.I.T.
Evolve to Open (EvO) – Junior Software Engineer
General Dynamics Misson Systems Canada
[email-masked]<mailto:[email-masked]>
403-295-5251<tel:(403)%20295-5251>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet