Re: [manet] [Technical Errata Reported] RFC8175 (6472)

["Velt, R. (Ronald) in 't" <[e-mail]>]

Hi Shawn,

Thanks and good to hear from you. Please see below.

From: Shawn Jury (sjury) <[e-mail]>
Sent: maandag 10 mei 2021 22:47
To: Velt, R. (Ronald) in 't <[e-mail]>; Alvaro Retana <[e-mail]>; Rick Taylor <[e-mail]>
Cc: [e-mail]; Shawn Jury (sjury) <[e-mail]>
Subject: Re: [Technical Errata Reported] RFC8175 (6472)

Hey Ronald,

    Some of what you are talking about is in Section 7.1 p4.  Check that out to see if it answers your concern.

To a degree it does, but not completely. I do admit that I had overlooked that paragraph. I’ll discuss more in reply to Rick Taylor’s mail of today.

    I have asked my developers to check how we handle this situation in our implementation.

OK

Ronald

--
Shawn Jury
Cisco Fed Systems Architect
Office:  919.392.6449
Cell:    919.225.4638


From: "Velt, R. (Ronald) in 't" <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 10, 2021 at 16:36
To: Alvaro Retana <[e-mail]<mailto:[e-mail]>>, Rick Taylor <[e-mail]<mailto:[e-mail]>>, "Shawn Jury (sjury)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

Hi,

I forwarded the message below to Henning Rogge in order to get one more datapoint on the question what current implementations do. (Maybe we should ask David Wiggins as well).

With respect to the text correction, I can see the issue with the double MUST. However, in the proposed alternative, there is no MUST at all, just a SHOULD (and a lower case ‘should’). Somehow, that does not seem entirely right to me. So far, I have not been able to come up with anything better, though. I’ll think about it some more. BTW, what about the phrasing of “If the Modem is not including IPv4 and IPv6 Connection Point Data Items …”; shouldn’t that read: “If the Modem is including neither an IPv4 Connection Point Data Item nor an IPv6 Connection Point Data Item …”? What if the Modem is including just a IPv6 Connection Point Data Item, but the Peer Discovery Signal was sent over IPv4 (or vice versa)? Should we elaborate here to stave off future errata?

Regards,
Ronald

From: Alvaro Retana <[e-mail]<mailto:[e-mail]>>
Sent: maandag 10 mei 2021 20:01
To: Rick Taylor <[e-mail]<mailto:[e-mail]>>; Velt, R. (Ronald) in 't <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [Technical Errata Reported] RFC8175 (6472)

Ping!


On March 29, 2021 at 2:04:35 PM, Alvaro Retana ([e-mail]<mailto:[e-mail]>) wrote:
[- Rick’s additional address, RFC Editor, other ADs.]


On March 10, 2021 at 11:05:03 AM, Rick Taylor wrote:


Hi!

I'm processing this report...but I have a question.  What do current implementations do?  See move below.


...
> > Section: 12.4, para 2
> >
> > Original Text
> > -------------
> > A Peer Offer Signal MUST be encoded within a UDP packet. The IP source
> > and destination fields in the packet MUST be set by swapping the values
> > received in the Peer Discovery Signal. The Peer Offer Signal completes the
> > discovery process; see Section 7.1.
> >
> > Corrected Text
> > --------------
> > A Peer Offer Signal MUST be encoded within a UDP packet. If the Modem is
> > not including IPv4 and IPv6 Connection Point Data Items in the Peer Offer
> > Signal, then the IP source field in the packet MUST be set to the unicast
> > address the router must use when connecting the DLEP TCP session,
> > otherwise any valid local address MUST be used. The IP destination field
> > in the packet MUST be set to the IP source field value received in the
> > Peer Discovery Signal. The Peer Offer Signal completes the discovery
> > process; see Section 7.1.
> >
> > Notes
> > -----
> > The original text will not result in a valid unicast IP packet.


The new text is this:

   If the Modem is not including IPv4 and IPv6 Connection Point Data Items in
   the Peer Offer Signal, then the IP source field in the packet MUST be set
   to the unicast address the router must use when connecting the DLEP TCP
   session, otherwise any valid local address MUST be used.

I am having an issue with the double MUST.  Regardless of whether a Connection Point Data Item is present, why wouldn't it be required (or at least recommended) to always use the TCP-related IP address?

Proposal (to replace the new text)>
   The source IP address SHOULD be the address the peer should use when
   connecting the DLEP TCP session.  If a Connection Point Data Item is
   included, any valid local address MAY be used instead.


??

Thanks!

Alvaro.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.