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:

" ...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."

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 <Anthony.Tran@gd-ms.ca>
wrote:

> 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
>
> Anthony.Tran@gd-ms.ca
>
> 403-295-5251 <(403)%20295-5251>
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>