Subject: IPv6 options defined outside of 6man

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Nov 2016 09:16:36 +0100 (CET)

Hi,

I just the other day noticed that RFC7710 defines RA type for captive 
portal URI along DHCPv4 and DHCPv6 options for the same use.

http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 
lists the options currently defined.

This option was discussed briefly in 6man in March 2015, and then I saw no 
announcement of this actually being approved.

I found out in IDR the other day that any IETF working group can ask IANA 
to allocate numbers in any registries, and normally this goes to 
respective AD and WG who would then normally either allocate an expert to 
review, and/or have the entire WG review it.

I previously thought respective WG "owned" certain IANA option space they 
typically work with. This is not the case. Even people in IDR thought IDR 
"owned" certain IANA option space, and they were also wrong.

So do we here in 6man want some kind of process and consensus calling 
before this review is concluded and we say "no objection" when other WGs 
define IPv6 related options?

I believe DHC working group does this, they bring up options for 
discussions there before they're ACKed.

Thoughts?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Nov 2016 17:23:34 +0900

In addition, the 6man charter has explicit provisions to review any
document that "extends or modifies the IPv6 protocol", of which I think
neighbour discovery is a part.

======
6man is the design authority for extensions and modifications to the
IPv6 protocol. The working group may, at its discretion, review any
document produced in another working group that extends or modifies the
IPv6 protocol and, in consultation with the responsible ADs of both
working groups, may recommend to the IESG that 6man working group
consensus is needed before any of those documents can progress for
publication.
======

On Wed, Nov 16, 2016 at 5:16 PM, Mikael Abrahamsson <[email-masked]>
wrote:

> http://www.iana.org/assignments/icmpv6-parameters/icmpv6-
> parameters.xhtml#icmpv6-parameters-5 lists the options currently defined.
>
> to allocate numbers in any registries, and normally this goes to respective
> AD and WG who would then normally either allocate an expert to review,
> and/or have the entire WG review it.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Nov 2016 18:47:11 +0900

Le 16/11/2016 à 17:16, Mikael Abrahamsson a écrit :
> This option was discussed briefly in 6man in March 2015, and then I saw
> no announcement of this actually being approved.
>
> I found out in IDR the other day that any IETF working group can ask
> IANA to allocate numbers in any registries, and normally this goes to
> respective AD and WG who would then normally either allocate an expert
> to review, and/or have the entire WG review it.
>
> I previously thought respective WG "owned" certain IANA option space
> they typically work with. This is not the case. Even people in IDR
> thought IDR "owned" certain IANA option space, and they were also wrong.
>

This would be reasonable to do, I think.

> discussions there before they're ACKed.

I agree, as long as it gets constructive feedback from 6man.

Alex

---

From: t.petch <[email-masked]>
Date: Thu, 17 Nov 2016 10:53:01 +0000

----- Original Message -----
From: "Mikael Abrahamsson" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 16, 2016 8:16 AM
> portal URI along DHCPv4 and DHCPv6 options for the same use.
http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtm
l#icmpv6-parameters-5
> I found out in IDR the other day that any IETF working group can ask
IANA
> respective AD and WG who would then normally either allocate an expert
to
> review, and/or have the entire WG review it.

Well, no.

The document that sets up the registry defines the update procedure and
for

IPv6 Neighbor Discovery Option Formats

that is 'IETF RFC publication'.

This process is not defined in RFC5226, the current standard for IANA
Considerations, but could be considered as coming under 'IETF Review'
which calls for
           "The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

            To ensure adequate community review, such documents are
            shepherded through the IESG as AD-sponsored (or WG)
            documents with an IETF Last Call."
so the onus is on the AD to recognise that a wider involvement is needed
and to liaise with the relevant WGs (which many WG Chairs will have done
as a matter of course).

The concept of the WG is largely absent from RFC5226; it even says
"One might think that an IETF working
   group (WG) familiar with the namespace at hand should be consulted.
   In practice, however, WGs eventually disband, so they cannot be
   considered a permanent evaluator.  "
so IESG, IETF, ADs yes, WG no!

Tom Petch

> I previously thought respective WG "owned" certain IANA option space
they

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2016 08:21:10 +1300

> that is 'IETF RFC publication'.

If we don't think that is sufficient, we could update it to anything
we want (subject to IETF Last Call and IESG approval). The options
in RFC5226 (better, in RFC5226bis) are not exclusive: we could write
our own rules.

...
> so IESG, IETF, ADs yes, WG no!

Certainly if we updated the rules to specify 6man as the venue, we'd
need language to cover 6man being closed.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 18 Nov 2016 01:09:41 +0000

On 16 Nov 2016, at 08:16, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I just the other day noticed that RFC7710 defines RA type for captive portal URI along DHCPv4 and DHCPv6 options for the same use.

http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 lists the options currently defined.

This option was discussed briefly in 6man in March 2015, and then I saw no announcement of this actually being approved.

The document seems to have something of an unusual history. Looking in the Data Tracker, it is recorded as progressing as a non-WG document tagged as targeted to the dhc WG, but then got published without being adopted there - see https://tools.ietf.org/html/draft-wkumari-dhc-capport-16.

But, as you point out, it did have 6man review through an Internet Area AD request - https://www.ietf.org/mail-archive/web/ipv6/current/msg22066.html - and the only clear objections were from Mark Smith.

Whether it gets implemented by anyone is another question.

OTOH I could look forward to seeing people playing with the new IPv6 RA Rickrolling option. Who will be the first victim?

I found out in IDR the other day that any IETF working group can ask IANA to allocate numbers in any registries, and normally this goes to respective AD and WG who would then normally either allocate an expert to review, and/or have the entire WG review it.

I previously thought respective WG "owned" certain IANA option space they typically work with. This is not the case. Even people in IDR thought IDR "owned" certain IANA option space, and they were also wrong.

So do we here in 6man want some kind of process and consensus calling before this review is concluded and we say "no objection" when other WGs define IPv6 related options?

I believe DHC working group does this, they bring up options for discussions there before they're ACKed.

Thoughts?

I assumed this happened already. It did in this case, except there was never any formal “I conclude this” from the AD who requested the review at the end of it. That would have been helpful, but ADs are busy people.

Tim

---

From: joel jaeggli <[email-masked]>
Date: Mon, 21 Nov 2016 01:48:07 -0800

On 11/17/16 5:09 PM, Tim Chown wrote:
>> This option was discussed briefly in 6man in March 2015, and then I
>> saw no announcement of this actually being approved.
>
> The document seems to have something of an unusual history. Looking in
> the Data Tracker, it is recorded as progressing as a non-WG document
> tagged as targeted to the dhc WG, but then got published without being
> adopted there -
> see https://tools.ietf.org/html/draft-wkumari-dhc-capport-16. 
FWIW fully some dicussion in various places we decided to AD sponsor
this on the assumption that we could get adequate review, I think by in
large that was vindicated by the resulting process. Some discussion that
the document engendered resulted in the eventual formation of the
capport working group.

https://datatracker.ietf.org/wg/capport/charter/

> But, as you point out, it did have 6man review through an Internet
> Area AD request
> - https://www.ietf.org/mail-archive/web/ipv6/current/msg22066.html -
> and the only clear objections were from Mark Smith. 
>
> OTOH I could look forward to seeing people playing with the new IPv6
> RA Rickrolling option. Who will be the first victim?
>
>> respective AD and WG who would then normally either allocate an
>> expert to review, and/or have the entire WG review it.
>>
>> before this review is concluded and we say "no objection" when other
>> WGs define IPv6 related options?
>>
> I assumed this happened already. It did in this case, except there was
> never any formal “I conclude this” from the AD who requested the
> review at the end of it. That would have been helpful, but ADs are
> busy people.

Registry policies are established at the creation of the registry

in the case of

The Registration Procedure is

IETF RFC publication

for

DHCPv6 Option Codes

Expert Review and Standards Action

Area directors and iana review are expected to hew to requirements
specified in the registries and the doucments which created them.

Standards track documents may of course amend the procedures associated
with a registry.

---

From: Tim Chown <[email-masked]>
Date: Mon, 21 Nov 2016 10:46:54 +0000

Hi,

> On 21 Nov 2016, at 09:48, joel jaeggli <[email-masked]> wrote:

>> <snip>

> Standards track documents may of course amend the procedures associated

So, I guess the question for 6man is whether "Expert Review and Standards Action” should also formally be required for new IPv6 Neighbor Discovery Option Formats?  Even if it seems to be common practice at the moment.  Something to consider when 4861-bis comes up.

Tim

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 21 Nov 2016 12:08:42 +0100 (CET)

On Mon, 21 Nov 2016, Tim Chown wrote:

> So, I guess the question for 6man is whether "Expert Review and 
> Standards Action” should also formally be required for new IPv6 Neighbor 
> Discovery Option Formats?  Even if it seems to be common practice at the 
> moment.  Something to consider when 4861-bis comes up.

I have several concerns in this area.

We seem to have no IANA registry for some flags and perhaps options in 
IPv6 protocols. It's my opinion that all flags/options should have IANA 
registry so it's easy to see what has been taken and by what RFC it's 
defined in.

I would also like to see request for new options/code points of all kinds 
to go through proper 6man formal review process where the outcome of the 
process is announced and then given a grace period before it's passed on.

---

From: Tim Chown <[email-masked]>
Date: Mon, 21 Nov 2016 11:11:03 +0000

> On 21 Nov 2016, at 11:08, Mikael Abrahamsson <[email-masked]> wrote:
> 
> We seem to have no IANA registry for some flags and perhaps options in IPv6 protocols. It's my opinion that all flags/options should have IANA registry so it's easy to see what has been taken and by what RFC it's defined in.

Yes, this seems to be a gap. 

> I would also like to see request for new options/code points of all kinds to go through proper 6man formal review process where the outcome of the process is announced and then given a grace period before it's passed on.

I agree - for ND this currently just says “by RFC publication” in Section 13 of RFC 4861.

Tim

---

From: t.petch <[email-masked]>
Date: Tue, 22 Nov 2016 09:55:49 +0000

----- Original Message -----
From: "Tim Chown" <[email-masked]>
To: "joel jaeggli" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 21, 2016 10:46 AM

I see 'Expert Review' as something of a political solution to a
technical problem.  It requires that an expert be found, a backup expert
when the first is busy, the maintenance of the list of experts over a
spell of several years when, mostly, the IETF does not have an obvious
source of expertise (such as a WG).  All of which places a further
burden on ADs and the IESG, which, naturally, I expect them to resist.
Note too that 'Expert Review' comes just above First-Come First-Served
in the IANA heirarchy and below anything involving an RFC so the role is
a relatively weak one, and probably inappropriate for a core protocol.
And while it is meant to be open, I see it as often being secretive - it
is there for IANA's benefit, not for that of the IETF.

If there is a WG, and if the WG is a process rather than project one,
e.g. TCPM or IDR, then I think that the WG is the better place to go.

Tom Petch

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Nov 2016 13:15:02 +0000

Hi,

> On 22 Nov 2016, at 09:55, t.petch <[email-masked]> wrote:
> 
> source of expertise (such as a WG).  

Well, the “Expert” is typically a WG. In the case of the capport RA/ND option, a review was requested by an AD on the 6man list. The only thing I think that was missing was a summary of the outcome of the review (it wasn’t posted to the original thread, that I could see). In this case, only one objection was made.

> All of which places a further

The IESG reviews all I-Ds, but even with many expert eyes, some things can get missed, e.g. the .home issue in homenet.  Some Areas, e.g. Ops and Internet, have a system where the ADs get help from volunteers to provide extra review; a problem there though is not everyone can be “expert" in everything.

> e.g. TCPM or IDR, then I think that the WG is the better place to go.

I think there are different types of issues that may arise; some may be technical, some may be more architectural, and some may be “religious”. It’s tricky. But I think ensuring there’s a flag waved in (say) 6man for a proposal for a new ND option makes sense; worst case it will delay publication a week or two during the review period, which could always be done in the IETF LC period anyway, I assume.

Tim