Subject: [v6ops] draft-shytyi-v6ops-danir

From: Ron Bonica <[email-masked]>
Date: Mon, 17 Sep 2018 08:15:22 +0000

Folks,

Each week between now and IETF 103, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-shytyi-v6ops-danir

                                                             Fred and Ron

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Sep 2018 10:37:40 +0200

> This week, please review and comment on draft-shytyi-v6ops-danir

This document reads like the notes an implementor wrote when doing an implementation.
It contains snippets from the standard documents used, packets formats and so on.

One could have hoped for some specific implementation advice or findings of holes or ambiguities in the underlaying standards. I find no indication of that in the document.
If an ennumeration of how to implement a “CE style router” is needed I am unsure if this adds much over what’s already in RFC7084.

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Sep 2018 18:42:13 +0200

Thank you for looking at our draft!

We take the advice and will maybe update the draft accordingly.

One recommendation we suggest for DHCP is to _not_ use port 547 because
many people block it.  Use another one, like 25474, or maybe create a
method to dynamically negotiate such port number.

Another may have to do with Hop Limit and multicast scope in DHCP 
Solicit messages.  Make it larger and it will allow to put DHCP servers 
_outside_ the cellular network domain, and work with port numbers that 
we want, not only those that are imposed by RFC and blocked by those who 
ignore RFC.

-------------------------------------------------------------------------
Below this there is ranting.

Another recommendation I have is that the link layer protocol used to
make IPv6 addresses in 3GPP network be documented - and agreed - at
IETF, not only at 3GPP.  Without such document and agreement it is next
to impossible to discuss meaningfully about IPv6 and User Equipments at
IETF.

But I agree this latter recommendation is probably hard to follow.  It
needs much hardware and other expensive ressources and commitment,
together with an open mind.  Moreover, many people say such
recommendations are useless, because each SDO with its own tech.

(it's in the same list of recommendations I have, like the one to
document the Human Rights in an IETF document, rather than referring to
some 1947 UN outdated text).

> This document reads like the notes an implementor wrote when doing an

Yes, that is it.  I think there is nothing remotely even wrong with 
that, and it is a good way to write documents.

> used, packets formats and so on.

YEs, again, packet formats is what protocols are about.  The inner 
working of a protocol is in its packet format and field description.

Moreover, these are packets captured on the network, i.e. running code.

> 
> One could have hoped for some specific implementation advice or
> findings of holes or ambiguities in the underlaying standards. I find
> no indication of that in the document. If an ennumeration of how to
> implement a “CE style router” is needed I am unsure if this adds much
> over what’s already in RFC7084.

What is the RFC7084 'title'?

It is very often hard to follow discussions where there is talk about 
RFC numbers but we dont know what is the RFC about.  There are almost 
10.000 RFCs out there.  We know some of them by heart, but others no.

Of course, one could say this: with the RFC number just google and find 
it.  But there is some additional work to do: open the browser, type in, 
make sure you select the right answer, click, scroll, and read some 
part.  This work could have been saved by typing a short version of the 
title in the email referring to it.

Alex

> 
> Ole
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Dmytro Shytyi <[email-masked]>
Date: Mon, 17 Sep 2018 19:11:19 +0200

Hello, Thank you for considering of the draft-shytyi-v6ops-danir :) Your comments are valuable for us. Also we have updated nits, but did not submit the new versoin of the draft yet. I support the Alexandre Petrescu statement.  After these comments in the next version we may add the next information: Recommendation #1: Hop limit should be set to some (say 42*) value to avoid "packet drop" on the path to the DHCP server. Recommendation #2: DHCP in the cellular environment should use different port (static or via negotiaiton method) *https://en.wikipedia.org/wiki/42_(number)#The_Hitchhiker's_Guide_to_the_Galaxy "The number 42 is, in The Hitchhiker's Guide to the Galaxy by Douglas Adams, the "Answer to the Ultimate Question of Life, the Universe, and Everything", calculated by an enormous supercomputer named Deep Thought over a period of 7.5 million years. Unfortunately, no one knows what the question is. Thus, to calculate the Ultimate Question, a special computer the size of a..." ______________ Dmytro SHYTYI ---- On Mon, 17 Sep 2018 18:42:13 +0200 Alexandre Petrescu <[email-masked]> wrote ---- Thank you for looking at our draft! We take the advice and will maybe update the draft accordingly. One recommendation we suggest for DHCP is to _not_ use port 547 because many people block it. Use another one, like 25474, or maybe create a method to dynamically negotiate such port number. Another may have to do with Hop Limit and multicast scope in DHCP Solicit messages. Make it larger and it will allow to put DHCP servers _outside_ the cellular network domain, and work with port numbers that we want, not only those that are imposed by RFC and blocked by those who ignore RFC. ------------------------------------------------------------------------- Below this there is ranting. Another recommendation I have is that the link layer protocol used to make IPv6 addresses in 3GPP network be documented - and agreed - at IETF, not only at 3GPP. Without such document and agreement it is next to impossible to discuss meaningfully about IPv6 and User Equipments at IETF. But I agree this latter recommendation is probably hard to follow. It needs much hardware and other expensive ressources and commitment, together with an open mind. Moreover, many people say such recommendations are useless, because each SDO with its own tech. (it's in the same list of recommendations I have, like the one to document the Human Rights in an IETF document, rather than referring to some 1947 UN outdated text). Le 17/09/2018 à 10:37, Ole Troan a écrit : >> This week, please review and comment on draft-shytyi-v6ops-danir > > This document reads like the notes an implementor wrote when doing an > implementation. Yes, that is it. I think there is nothing remotely even wrong with that, and it is a good way to write documents. > It contains snippets from the standard documents > used, packets formats and so on. YEs, again, packet formats is what protocols are about. The inner working of a protocol is in its packet format and field description. Moreover, these are packets captured on the network, i.e. running code. > > One could have hoped for some specific implementation advice or > findings of holes or ambiguities in the underlaying standards. I find > no indication of that in the document. If an ennumeration of how to > implement a “CE style router” is needed I am unsure if this adds much > over what’s already in RFC7084. What is the RFC7084 'title'? It is very often hard to follow discussions where there is talk about RFC numbers but we dont know what is the RFC about. There are almost 10.000 RFCs out there. We know some of them by heart, but others no. Of course, one could say this: with the RFC number just google and find it. But there is some additional work to do: open the browser, type in, make sure you select the right answer, click, scroll, and read some part. This work could have been saved by typing a short version of the title in the email referring to it. Alex > > Ole > > _______________________________________________ v6ops mailing list > [email-masked] https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops