Subject: 6MAN Adoption call on draft-gont-6man-lla-opt-validation

From: Ole Troan <[email-masked]>
Date: Wed, 5 Mar 2014 10:25:30 +0000

This is an adoption call of draft-gont-6man-lla-opt-validation.
Please provide your view with reasons as to whether the WG should adopt this or not.

This call will end on 2014-03-19.

Best regards,
Ole and Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Mar 2014 23:55:53 +1300

In my opinion this draft describes real risks and real
mitigations, so I support adoption on the standards track.

I see that it's tagged "Updates: 4861". Actually I think that
is strictly speaking wrong: it *adds* requirements but it doesn't
change anything in 4861 (unless I've missed it). I wouldn't object
to the tag since it will in theory mean that an implementor has
a better chance of finding the new document.

I suggest including a sentence in the Introduction that says something
like "This document updates RFC 4861 by requiring that hosts perform
additional checks" or something like that.

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 5 Mar 2014 11:14:32 +0000

Support the adoption, also Brian's suggestion that there is only additional content in this draft, rather than updating 4861.

Sheng
________________________________________
From: ipv6 [[email-masked]] on behalf of Brian E Carpenter [[email-masked]]
Sent: 05 March 2014 18:55
To: Ole Troan
Cc: 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on draft-gont-6man-lla-opt-validation

   Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Wed, 05 Mar 2014 07:24:00 -0500

6MAN WG,

> Please provide your view with reasons as to whether the WG should adopt this or not.

If the WG decides to adopt this document, I would strongly encourage the
expansion of the draft to consider validation of other fields in NDP
messages/options.  I don't want to see the WG publish guidance on these
LLA options and then six months later publish guidance on some other
field/option.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 05 Mar 2014 12:03:44 -0300

> a better chance of finding the new document.

This was the intent.

> additional checks" or something like that.

I will modify the I-D as suggested.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Philip Matthews <[email-masked]>
Date: Thu, 6 Mar 2014 12:10:49 +0000

I support the adoption of this work, but I wonder if it would not be better to publish a revision of rfc4861?
I really like the fact that 6MAN has managed to keep its core documents more-or-less up-to-date.
It s very hard to keep track of what the spec is if there are lots of little documents that modify it.

Since there is additional work on ND being discussed right now, perhaps the approach should be: Adopt this draft for now as a WG item, with the intention that it will be folded into a revision of 4861 before publishing it as an RFC.

Just a suggestion.

- Philip

---

From: 神明達哉 <[email-masked]>
Date: Mon, 10 Mar 2014 10:00:17 -0700

At Wed, 5 Mar 2014 10:25:30 +0000,

> Please provide your view with reasons as to whether the WG should adopt this or not.

I support the adoption of the draft.  At this moment, I'm not sure if
the end result is to publish it as an RFC, but the described issues
seem to be worth discussing.

--
JINMEI, Tatuya

---

From: Bob Hinden <[email-masked]>
Date: Tue, 25 Mar 2014 13:38:21 -0700

The chairs, after reviewing the discussion on this adoption call, think there is interest in this work.  We also agree it is not an update to RFC 4861, more like guidance to implementers.

However we are not sure it makes sense to publish an RFC that only addresses these two issues.  It's going to get very complicated if we end up with a large number of RFCs each addressing a few fields.

As our AD said in his response:

> LLA options and then six months later publish guidance on some other

Would the w.g. be interested in doing a comprehensive review of ND and produce a single RFC that provides guidance on a broader range of neighbor discovery fields?

Bob & Ole

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 26 Mar 2014 21:49:53 +0000

Bob,

The authors would be glad to expand the scope of this document to include validation for all ND options. This would include:

- the SLLA Option
- the TLLA Option
- Prefix Information
- Redirect Header 
- MTU

                         Ron

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Tuesday, March 25, 2014 4:38 PM
To: [email-masked]
Cc: Bob Hinden
Subject: Re: 6MAN Adoption call on draft-gont-6man-lla-opt-validation

On Mar 5, 2014, at 4:24 AM, Brian Haberman <[email-masked]> wrote:

> If the WG decides to adopt this document, I would strongly encourage 
> the expansion of the draft to consider validation of other fields in 
> NDP messages/options.  I don't want to see the WG publish guidance on 
> these LLA options and then six months later publish guidance on some 
> other field/option.

Bob & Ole

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 27 Mar 2014 01:12:25 -0700 (PDT)

I think that would be a good thing to do.

----- Original Message -----
> From: Ronald Bonica <[email-masked]>
> To: Bob Hinden <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Thursday, 27 March 2014 8:49 AM
> Subject: RE: 6MAN Adoption call on draft-gont-6man-lla-opt-validation
> 
> Bob,
> 
> The authors would be glad to expand the scope of this document to include 
> validation for all ND options. This would include:
> 
> - the SLLA Option
> - the TLLA Option
> - Prefix Information
> - Redirect Header 
> - MTU
> 
>                          Ron
> 
> 
> 
> The chairs, after reviewing the discussion on this adoption call, think there is 
> interest in this work.  We also agree it is not an update to RFC 4861, more like 
> guidance to implementers.
> 
> However we are not sure it makes sense to publish an RFC that only addresses 
> these two issues.  It's going to get very complicated if we end up with a 
> large number of RFCs each addressing a few fields.
> 
> Would the w.g. be interested in doing a comprehensive review of ND and produce a 
> single RFC that provides guidance on a broader range of neighbor discovery 
> fields?
> 
> Bob & Ole
> 
> 
>