Subject: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204)

From: David Kessens <[email-masked]>
Date: Fri, 18 Jan 2013 17:16:41 -0800

Hi,

I would hereby like to start a Last Call for:

http://tools.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-01 

This document is needed in order to move:

 http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08
 http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07
 http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06

towards the IESG and publication.

Please indicate your support by February 4, 2012. Or alternatively, let us
know in the same timeframe whether there are still issues that need to be
resolved.

Thanks!

David Kessens
co-chair netmod wg
---

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 20 Jan 2013 09:55:29 +0000

Hi,

Does this document obsolete RFC6021? The header says nothing about this. 

Is this an official WG document? If so, why is it not named draft-ietf-netmod-rfc6021bisp... or something similar? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Kessens
> Sent: Saturday, January 19, 2013 3:17 AM
> To: [email-masked]
> Subject: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01
> (20130204)
> 
> 
> Hi,
> 
> Please indicate your support by February 4, 2012. Or alternatively, let
> us know in the same timeframe whether there are still issues that need
> to be resolved.
> 
> Thanks!
> 
> David Kessens
> co-chair netmod wg
> ---
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 20 Jan 2013 11:40:44 +0100

> Does this document obsolete RFC6021? The header says nothing about this. 

This is the idea. I have added a sentence to the abstract and the
obsoletes header line.
 
> Is this an official WG document? If so, why is it not named draft-ietf-netmod-rfc6021bisp... or something similar? 

I guess we will know after the WG last call whether the WG has
agreement to put the definitions needed by the other WG documents into
this document. But this is really for David to explain if more
explanation is needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Jan 2013 08:36:25 +0100 (CET)

Hi,

> http://tools.ietf.org/id/draft-schoenw-netmod-rfc6021-bis-01 

I have reviewed this document, and I support it moving forward.

Some comments though:

The pattern for hex-string is:

  pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';

it should be:

  pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*';

The pattern for uuid is:

   pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}'
         + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}';

it should be:

   pattern '[0-9a-fA-F]{4}-[0-9a-fA-F]{2}-[0-9a-fA-F]{2}-'
         + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}';

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jan 2013 09:13:49 +0100

>   pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*';

Fixed. 
 
>          + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}';

Yes, indeed. Fixed.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Jan 2013 09:35:43 +0100 (CET)

> >          + '[0-9a-fA-F]{2}-[0-9a-fA-F]{6}';

Actually, a collegue of mine just pointed out that it should be:

   pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
         + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jan 2013 09:41:59 +0100

>          + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';

Why? I am trying to follow RFC 4122 section 3.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Jan 2013 09:47:50 +0100 (CET)

> Why? I am trying to follow RFC 4122 section 3.

Yes.  It says e.g. 

      time-low               = 4hexOctet

but an hexOctet is defined as:

      hexOctet               = hexDigit hexDigit

so time-low consists of 8 hex digits.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jan 2013 09:58:01 +0100

> so time-low consists of 8 hex digits.

Thanks, now I got it. Fixed.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Jan 2013 14:28:43 +0100

Hi,

I support moving this document forward, with two comments:

1. The second pattern for "yang-identifier" type can be slightly optimized:

OLD

    pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';

NEW

    pattern '..?|[^xX].*|.[^mM].*|..[^lL].*';

2. It would be safer to have types 'ipv[46]-address' (meaning no zone) and 'ipv[46]-address-with-zone' rather than 'ipv[46]-address' and 'ipv[46]-address-no-zone'. I know, it's an incompatible change, but I suspect that many implementers will not bother to look up the definition when seeing a type like 'ipv4-address' and assume a plain IPv4 address in that place. Such a mistake can easily create a security hole. The name 'ipv[46]-address-with-zone' makes the optional presence of a zone index explicit and eliminates this potential trap. Besides, it would also better fit the naming scheme of corresponding textual conventions in RFC 4001.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jan 2013 14:39:52 +0100

>     pattern '..?|[^xX].*|.[^mM].*|..[^lL].*';

Not sure what the metric is that is optimized here or how to choose
between the two.
 
> 2. It would be safer to have types 'ipv[46]-address' (meaning no zone) and 'ipv[46]-address-with-zone' rather than 'ipv[46]-address' and 'ipv[46]-address-no-zone'. I know, it's an incompatible chan…

It is still an incompatible change. We can't change 'ipv[46]-address'.
We can deprecate it and provide a replacement.

Personally, I do not think this is needed or desirable. The IPv6 WG
just reached concensus to allow zone indexes in URIs and there was no
a concern that this creates a security hole as far as I understand.
What might happen is that people forget to implement support for
addresses including a zoneid. That said, for stuff sitting above the
IP layer, having zones included 'by default' is in my view a feature
and not a bug.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Jan 2013 15:51:06 +0100

> Not sure what the metric is that is optimized here or how to choose

The metric is string length and the number of alternatives.

> We can deprecate it and provide a replacement.

This is not an option in this case - we can't deprecate a typedef such as "ipv4-address" and introduce a new one with the same name. 

> a concern that this creates a security hole as far as I understand.

In URIs, IP addresses (with or without zone indices) are enclosed in brackets. In our case, the zone index is an arbitrarily long suffix without any delimiters.

> IP layer, having zones included 'by default' is in my view a feature

OK, let me just mention that both I and Martin already fell into that trap, and so did the authors of the dnsccm module, I think:

http://dnsccm.org/projects/dnsccm/repository/entry/trunk/dnsccm/modules/dnsccm/dnsccm.in.yang

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jan 2013 16:29:06 +0100

> The metric is string length and the number of alternatives.

Well...
 
> This is not an option in this case - we can't deprecate a typedef such as "ipv4-address" and introduce a new one with the same name. 

I did not say same name...
 
> In URIs, IP addresses (with or without zone indices) are enclosed in brackets. In our case, the zone index is an arbitrarily long suffix without any delimiters.

How is that different?

> http://dnsccm.org/projects/dnsccm/repository/entry/trunk/dnsccm/modules/dnsccm/dnsccm.in.yang

I can't judge where they did fall into a trap. Perhaps they got things
right - I really can't judge.

Anyway, please make an actionable concrete proposal if you want. I do
not think we are going to break YANG update rules for this. Hence your
initial proposal does not seem actionable.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Jan 2013 16:40:36 +0100

> initial proposal does not seem actionable.

If there is nobody else who thinks it might be a problem, let's keep the current typedefs.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Mon, 21 Jan 2013 11:48:55 -0500

Martin Bjorklund writes:
>The pattern for hex-string .....

Why not support "f:0:4:3:3:1" (single digits)?

Do we canonicalize to upper or lower case?

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Jan 2013 18:08:08 +0100

> Why not support "f:0:4:3:3:1" (single digits)?

Never seen that before.
 
> Do we canonicalize to upper or lower case?

The full definition reads like this:

  typedef hex-string {
    type string {
      pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*';
    }
    description
     "A hexadecimal string with octets represented as hex digits
      separated by colons.  The canonical representation uses 
      lowercase characters.";
  }

/js

---

From: David Kessens <[email-masked]>
Date: Tue, 22 Jan 2013 20:52:57 -0800

Dan,

> Does this document obsolete RFC6021? The header says nothing about this. 

for completeness sake: yes

> Is this an official WG document? If so, why is it not named draft-ietf-netmod-rfc6021bisp... or something similar? 

We are jumping the gun a bit here: it is not really about a new document,
but putting the already agreed upon content it in a new version of another
already published document.

So yes, the Last Call is about getting it published and making it a wg
document at the same time. The last was implicit but I should have called
that out.

Having said this, it seems a new version will be necessary anyways and I
will be able to correct all this with better wording in a new Last Call of
a new and improved version.

I hope this helps, and let me know if you have any remaining concerns,

David Kessens
---

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 23 Jan 2013 09:13:39 +0100

IF you do a new revision and a new WGLC, then you might as well
rename the document to a wg document name (draft-ietf-netmod...) at
the same time.

Bert
----- Original Message ----- 
From: "David Kessens" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 23, 2013 5:52 AM
Subject: Re: [netmod] Last Call: draft-schoenw-netmod-rfc6021-bis-01 (20130204)

>> Is this an official WG document? If so, why is it not named 
>> draft-ietf-netmod-rfc6021bisp... or something similar?
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jan 2013 08:29:23 +0000

Hi David,

If the next version is renamed according to the naming convention for a WG document and the header reflects the obsolescence of RFC 6021 - no concern!

Thanks and Regards,

Dan

> From: David Kessens [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2013 6:53 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> > Is this an official WG document? If so, why is it not named draft-
> ietf-netmod-rfc6021bisp... or something similar?
> 
> We are jumping the gun a bit here: it is not really about a new
> document, but putting the already agreed upon content it in a new
> version of another already published document.
> 
> document at the same time. The last was implicit but I should have
> called that out.
> 
> will be able to correct all this with better wording in a new Last Call
> of a new and improved version.
>

---

From: David Kessens <[email-masked]>
Date: Wed, 23 Jan 2013 11:11:47 -0800

Dan, Bert, 

> If the next version is renamed according to the naming convention for a WG document and the header reflects the obsolescence of RFC 6021 - no concern!

&

> rename the document to a wg document name (draft-ietf-netmod...) at

That is indeed part of the plan!

David Kessens
---

David Kessens
---