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

["Taylor, Rick" <[e-mail]>]

Hi Ronald,

I think that’s pretty close to perfect.  Logically correct, but I do worry about the ‘neither … nor’ language.  That construct can confuse native language speakers so it cannot be easier for non-native, but I’m not one to judge.

Perhaps a US-English speaker (where I believe neither+nor is less common) would care to judge?

Cheers,

Rick

From: manet [mailto:[e-mail]] On Behalf Of Velt, R. (Ronald) in 't
Sent: Wednesday, May 12, 2021 4:04 PM
To: Rick Taylor <[e-mail]>; Shawn Jury (sjury) <[e-mail]>; Alvaro Retana <[e-mail]>
Cc: [e-mail]
Subject: Re: [manet] [Technical Errata Reported] RFC8175 (6472)

Hi Rick,

(inline)

From: manet <[e-mail]<mailto:[e-mail]>> On Behalf Of Rick Taylor
Sent: woensdag 12 mei 2021 10:38
To: Shawn Jury (sjury) <[e-mail]<mailto:[e-mail]>>; Velt, R. (Ronald) in 't <[e-mail]<mailto:[e-mail]>>; Alvaro Retana <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [manet] [Technical Errata Reported] RFC8175 (6472)

Hi All,

Just to clarify the issue.  RFC 8175, Section 7.1 p4 says that the Peer Offer is unicast back to the multicast address, which is obviously nonsense.

I don’t think Section 7.1 p 4 says that. Did you mean: "RFC 8175, Section 12.4 para 2 says that the Peer Offer is unicast back to the router with a multicast source address, which is obviously nonsense” ?

The other issue discovered, is that no mention is made of the UDP port to be used for the response.

My suggestion is that the correction is:

1.       The Peer Offer MUST be unicast back to the source IP address *and port* of the received multicast Peer Discovery signal.

Agree.

2.       The Source Address/Port of the Peer Offer signal MUST be the Address/Port to be used for the new TCP session, *unless* IPv4 and/or IPv6 Connection Point data items are included in which case the Address/Port combination are irrelevant.

I think this should read:

The Source Address/Port of the Peer Offer signal MUST be the Address/Port to be used for the new TCP session, *unless* IPv4 and/or IPv6 Connection Point data items are included. In the latter case, any valid local address and an arbitrary port number can be used.

(A namespace purist might object that in case the Peer Offer does not contain Connection Point data items, a UDP port number (in casu, the source port number of the Peer Offer) is re-interpreted / repurposed as a TCP port number).

This behaviour is consistent with the LL-DLEP (MIT) code, and our (Airbus) code.

Now we just need to turn that into ‘standards language’…   Is there MUST/UNLESS language in 8174 we can use?

Staying closer to corrected text you initially proposed:

   If the Modem is including neither IPv4 nor IPv6 Connection Point Data Items in the Peer Offer Signal, then the IP source field and the UDP source port in the packet MUST be set
   to the unicast address and the TCP destination port for the router to use when connecting the DLEP TCP session, otherwise any valid local address and an arbitrary port number can be used.

(With the same namespace caveat as above).

What do you think?

Ronald

Cheers,

Rick

From: Shawn Jury (sjury) [mailto:[e-mail]]
Sent: 10 May 2021 21:47
To: Velt, R. (Ronald) in 't; Alvaro Retana; Rick Taylor
Cc: [e-mail]<mailto:[e-mail]>; Shawn Jury (sjury)
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.

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

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



THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England