Subject: Revision of draft-ietf-6man-stable-privacy-addresses

From: Fernando Gont <[email-masked]>
Date: Sun, 19 May 2013 14:33:27 -0300

Folks,

I've posted a rev of the aforementioned document, meant to address the
comments received during IETF LC.

This rev is the result of the IETF LC discussions we had on the 6man wg
list and on the general IETF list, and of off-list discussions with a
number of folks who generously provided input, reviewed proposed
changes, etc.

I'd expect this rev to be "ready to ship" or very close to that. But
please provide your input confirming whether you think that's the case,
or whether there are any remaining issues to be solved.

The rev is available at:
<http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-07>.

A diff from the previous version of the I-D is available at:
<tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-06.txt&url2=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-07.txt>.

Thanks so much!

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

---

From: Christian Huitema <[email-masked]>
Date: Sun, 19 May 2013 18:29:06 +0000

> <http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-07>.

Nice job, Fernando. I have read this revision. I think it fairly reflects the comments from the WG.

-- Christian Huitema

---

From: Ray Hunter <[email-masked]>
Date: Sun, 19 May 2013 20:49:36 +0200

> Fernando Gont <mailto:[email-masked]>
> 19 May 2013 19:33
> Folks,
>
> ------------------------------------------------------------------------
I think the draft is looking very good and is "ready to go." I support it.

I'm not 100.00000% convinced by one sentence, but I can live with it.

Quote: "We note that this method is incrementally deployable, since it
does not pose any interoperability implications when deployed on
networks where other nodes do not implement or employ it."

AFAICS there's a very very unlikely race condition scenario where a node
implementing draft-ietf-6man-stable-privacy-addresses could cause a
collision of a link local address with a node implementing existing
SLAAC, because the node running draft-ietf-6man-stable-privacy-addresses
arrived on link first and completes DAD before the SLAAC node connects
to the link.

If the SLAAC node continues to deploy 4862 literally as defined in
Section5.4.5, it will completely shut down IPv6 on the affected
interface, unless it implements the MAY clause in 5.4.5 and continues
IPv6 operation, in which case there will be a possibility of a node that
runs IPv6 on an interface and which configures IPv6 GUA using SLAAC, but
does not have a link-local address on the link. [5.4.5 still bans
assigning any address failing DAD AFAICS, even though IPv6 operation is
permitted on the interface]

If the SLAAC node arrives on link first,
draft-ietf-6man-stable-privacy-addresses will back off, increment (and
presumably remember) the DAD counter and everything will work nominally.

To be clear, I think this is probably more of an issue with
draft-ietf-6man-ug-00 than draft-ietf-6man-stable-privacy-addresses-07.

It does beg the question which node should back off in this case (if
any). Probably the best course of action would be for the SLAAC node to
choose a different link local address. Although this could have
consequences, as e.g. static routes may point to the link local address.

This is already hinted at indraft-ietf-6man-stable-privacy-addresses-07,
Quote:  "Real world data indicates that MAC address reuse is far more
common than assumed [HDMoore].  This means that even IPv6 addresses that
employ (allegedly) unique identifiers (such as IEEE identifiers) might
result in DAD failures, and hence implementations should be prepared to
gracefully handle such occurrences." Which I agree with.

So in summary, I'd be happy if this was put on a "to consider" list for
draft-ietf-6man-ug-0

Some minor nits
s/shouldproduce/should produce/

s/The prefix to be used for SLAAC, as learned from an ICMPv6/ Router
Advertisement message./The prefix to be used for SLAAC, as learned from
an ICMPv6 Router Advertisement message, or the Link-Local IPv6 Unicast
prefix./

s/or when network interface happen/or when network interfaces happen/

/Privacy issues still present when temporary addresses are employed/
/employed/ is not bold after the new line (XML source or rendering
artefact?)
B1.3 has the same /server-like functions/ with /functions/ not in bold,
so it looks like the rendering.

s#It is not unusual for people to assume or expect that all the
security/privacy implications of traditional SLAAC addresses to me
   mitigated when "temporary addresses"#It is not unusual for people to
assume or expect that all security/privacy implications of traditional
SLAAC addresses are mitigated when "temporary addresses"#

Thanks.

regards,
RayH

---

From: james woodyatt <[email-masked]>
Date: Sun, 19 May 2013 12:31:13 -0700

> <tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-06.txt&url2=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-07.txt>.

I have a problem with the following set of requirements:

   The Net_Iface is a value that identifies the network interface for
   which an IPv6 address is being generated.  The following properties
   are desirable for the Net_Iface:

   o  it MUST be constant across system bootstrap sequences and other
      network events (e.g., bringing another interface up or down)

   o  it MUST be different for each network interface

Some hosts have dynamic logical network interfaces (distinguishable from physical interface), which are created every time the host joins a network, and destroyed when the host separates from a previously joined network.  Examples are typically interfaces that involve signaling systems, point-to-point connection semantics for the link layer, e.g. virtual private networks, automatic tunnels, et cetera.

According to these requirements, such hosts MUST NOT reuse previously generated stable privacy addresses when joining the same network with a new logical interface.  That seems counter to the goal of this standard.

I think hosts need some latitude in these requirements to allow for temporally different network interfaces associated with the same network service from the host's view to have the same identity for the purpose of generating stable privacy addresses.

--
james woodyatt <[email-masked]>
core os networking

---

From: Fernando Gont <[email-masked]>
Date: Sun, 19 May 2013 17:08:03 -0300

Hi, Ray,

Thanks so much for your feedback! -- Please find my comments in-line....

> I think the draft is looking very good and is "ready to go." I

Thanks!

> Quote: "We note that this method is incrementally deployable, since
> it does not pose any interoperability implications when deployed on 
> AFAICS there's a very very unlikely race condition scenario where a
> node implementing draft-ietf-6man-stable-privacy-addresses could
> cause a collision of a link local address with a node implementing
> existing SLAAC, because the node running
> draft-ietf-6man-stable-privacy-addresses arrived on link first and
> completes DAD before the SLAAC node connects to the link.
> 
> interface, unless it implements the MAY clause in 5.4.5 and
> continues IPv6 operation, in which case there will be a possibility
> of a node that runs IPv6 on an interface and which configures IPv6
> GUA using SLAAC, but does not have a link-local address on the link.
> [5.4.5 still bans assigning any address failing DAD AFAICS, even
> though IPv6 operation is permitted on the interface]

A few comments here:

1) Windows doesn't implement the traditional "embed the MAC address in
the IID" scheme -- so Windows nodes are not affected.

2) This "risk" is the price of one additional bit of entropy (another
approach would have been to clear the U/L bit).

3) Since there's quite a bit of MAC address reuse out there, nodes
should probably have to gracefully handle DAD failures anyway.

> draft-ietf-6man-stable-privacy-addresses will back off, increment
> (and presumably remember) the DAD counter and everything will work
> nominally.
> 
> draft-ietf-6man-ug-00 than
> draft-ietf-6man-stable-privacy-addresses-07.

At ome IETF meeting I argued that deprecating the u/g bit is fine, but
one should have a scheme to deal with DAD failures.

> This is already hinted at
> indraft-ietf-6man-stable-privacy-addresses-07, Quote:  "Real world
> data indicates that MAC address reuse is far more common than assumed
> [HDMoore].  This means that even IPv6 addresses that employ
> (allegedly) unique identifiers (such as IEEE identifiers) might 
> result in DAD failures, and hence implementations should be prepared
> to gracefully handle such occurrences." Which I agree with.
> 
> So in summary, I'd be happy if this was put on a "to consider" list
> for draft-ietf-6man-ug-0

Any changes required on draft-ietf-6man-stable-privacy-addresses?

> Some minor nits s/shouldproduce/should produce/

Done! -- THanks! (for some reason, I obtained a zero-length output when
trying to sue the spell-checker at tools.ietf.org)

> Advertisement message./The prefix to be used for SLAAC, as learned
> from an ICMPv6 Router Advertisement message, or the Link-Local IPv6
> Unicast prefix./

Fixed. Thanks!

> s/or when network interface happen/or when network interfaces

Fixed.

> /employed/ is not bold after the new line (XML source or rendering 

Yep -- the txt should be fine.

> B1.3 has the same /server-like functions/ with /functions/
> not in bold, so it looks like the rendering.

Yep.

> assume or expect that all security/privacy implications of
> traditional SLAAC addresses are mitigated when "temporary
> addresses"#

"be" rather than "are", actually?

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 19 May 2013 17:16:27 -0300

On 05/19/2013 04:31 PM, james woodyatt wrote:
> Some hosts have dynamic logical network interfaces (distinguishable
> from physical interface), which are created every time the host joins
> a network, and destroyed when the host separates from a previously
> joined network.  Examples are typically interfaces that involve
> signaling systems, point-to-point connection semantics for the link
> layer, e.g. virtual private networks, automatic tunnels, et cetera.
> 
> According to these requirements, such hosts MUST NOT reuse previously
> generated stable privacy addresses when joining the same network with
> a new logical interface.  That seems counter to the goal of this
> standard.

I'm not sure I follow... The requirement is that you address changes
when you move from one network to another. The only requirement for
"Net_Iface" must be different for different network interface is that
DAD failures are avoided (i.e., you don't have any two interfaces
deterministically getting the same address).

> I think hosts need some latitude in these requirements to allow for
> temporally different network interfaces associated with the same
> network service from the host's view to have the same identity for
> the purpose of generating stable privacy addresses.

If you use the interface index for Net_Iface, you'd probably get exactly
this. Same thing if you use the interface name (these virtual interfaces
are likely to get the same names when they are re-created?).

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 May 2013 08:23:03 +1200

On 20/05/2013 08:08, Fernando Gont wrote:
...
>> So in summary, I'd be happy if this was put on a "to consider" list

If you want to specify what to do after a DAD failure, I think that
is a separate issue. All we can reasonably do in draft-ietf-6man-ug is
mention the risk of IID collisions, I think.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Sun, 19 May 2013 23:19:44 +0200

> 19 May 2013 22:08

Do you happen to know how Windows behaves in this case?

Are we already effectively running with this (tiny) risk in production
but (I) just didn't know it?
> approach would have been to clear the U/L bit).
Agreed.
> should probably have to gracefully handle DAD failures anyway.
Agreed.
> one should have a scheme to deal with DAD failures.

It's not clear to me what exactly that scheme would do. But the current
text in 4862 isn't that helpful either.

I'd personally expect draft-ietf-6man-ug-00 to mention the issue, but
not necessarily to "solve" it. A full solution might require updating or
expanding 4862, and perhaps other standards, and I don't think it would
be desirable to deprecate the majority of existing running code just for
this issue.

Rather than forcibly clearing the U/L bit in the standard, another way
out without changing any standards text might be for implementers of
draft-ietf-6man-stable-privacy-addresses to be reasonably smart when
they read the text "The resulting Interface Identifier should be
compared against the Subnet-Router Anycast [RFC4291] and the Reserved
Subnet Anycast Addresses [RFC2526], and against those Interface
Identifiers already employed in an address of the same network interface
and the same network prefix."

So they'd basically loop whilst incrementing the DAD counter for any
Random Interface Identifier generated with u=1 if there's reason to
suspect that there were any nodes running existing SLAAC code on the
link, because the IID may well be in use, even though this particular
address hasn't explicitly failed DAD, nor has the developer been told
that generating an IID with u=1 is invalid.
> Any changes required on draft-ietf-6man-stable-privacy-addresses?
No. Not from my part.
> "be" rather than "are", actually?
"be" sounds either imperative (e.g. "be gone!") or old style English to me.

present tense of to be + past participle = "passive voice"

You could also consider:

#It is not unusual for people to assume, or expect, that enabling
"temporary addresses" [RFC4941] would mitigate all of the
   security/privacy implications of traditional SLAAC addresses.#

> Thanks!
>
> Best regards,
> Ray Hunter <mailto:[email-masked]>
> 19 May 2013 20:49

---

From: james woodyatt <[email-masked]>
Date: Sun, 19 May 2013 14:27:55 -0700

> deterministically getting the same address).

If avoiding DAD failure is the goal, then the second clause is overly restrictive. It should suffice that the value of Net_Iface is different for each network interface in *simultaneous* use.

> are likely to get the same names when they are re-created?).

That's not the sort of assumption I want to see go unstated in a Standards Track RFC. Better would be to avoid the ambiguity altogether.  For example, OS X does not have a requirement that network interfaces have unique names.  There is a UUID that identifies network services, which are related to the network interfaces the system configuration service manages, but network *services* on OS X are not the same as network *interfaces*, and they are not mapped 1:1 to one another.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 19 May 2013 18:42:44 -0300

> Do you happen to know how Windows behaves in this case?

No idea. -- Although it shouldn't be hard to find out with the ra6 tool
at <http://www.si6networks.com/tools/ipv6toolkit>

> but (I) just didn't know it?

Well, Windows node essentially select their stable addresses as a random
number, so... unless I'm missing something, we are.

> text in 4862 isn't that helpful either.

We'll it's left unspecified -- my take is that there's a gap in this area.

> not necessarily to "solve" it. 

+1

> A full solution might require updating or

Well, it wouldn't be "deprecate existing running code" (i.e., we're not
really against existing behaviour, but rather arguing about augmenting
it with graceful handling of DAD collisions).

> that generating an IID with u=1 is invalid.

Could that really be reliably determined?

> present tense of to be + past participle = "passive voice"

OK. Applied your original suggestion. :-)

Thanks so much!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 19 May 2013 18:52:50 -0300

On 05/19/2013 06:27 PM, james woodyatt wrote:
>>> The Net_Iface is a value that identifies the network interface
>>> for which an IPv6 address is being generated.  The following
>>> properties are desirable for the Net_Iface:
>>> 
>>> o  it MUST be constant across system bootstrap sequences and
>>> other network events (e.g., bringing another interface up or
>>> down)
>>> 
>>> Some hosts have dynamic logical network interfaces
>>> (distinguishable from physical interface), which are created
>>> every time the host joins a network, and destroyed when the host
>>> separates from a previously joined network.  Examples are
>>> typically interfaces that involve signaling systems,
>>> point-to-point connection semantics for the link layer, e.g.
>>> virtual private networks, automatic tunnels, et cetera.
>>> 
>>> According to these requirements, such hosts MUST NOT reuse
>>> previously generated stable privacy addresses when joining the
>>> same network with a new logical interface.  That seems counter to
>>> the goal of this standard.
>> 
>> I'm not sure I follow... The requirement is that you address
>> changes when you move from one network to another. The only
>> requirement for "Net_Iface" must be different for different network
>> interface is that DAD failures are avoided (i.e., you don't have
>> any two interfaces deterministically getting the same address).
> 
> If avoiding DAD failure is the goal, 

Yes.

> then the second clause is overly
> restrictive. It should suffice that the value of Net_Iface is
> different for each network interface in *simultaneous* use.

mm... how would you define simultaneous use?

Is an interface that is down considered "in use"? If not, is the
"Net_face" for that interface expeted to change (to comply with req #2)
when the interface is brought up?

>>> I think hosts need some latitude in these requirements to allow
>>> for temporally different network interfaces associated with the
>>> same network service from the host's view to have the same
>>> identity for the purpose of generating stable privacy addresses.
>> 
>> If you use the interface index for Net_Iface, you'd probably get
>> exactly this. Same thing if you use the interface name (these
>> virtual interfaces are likely to get the same names when they are
>> re-created?).
> 
> That's not the sort of assumption I want to see go unstated in a
> Standards Track RFC. Better would be to avoid the ambiguity
> altogether.  For example, OS X does not have a requirement that
> network interfaces have unique names.

How do you ifconfig(8) them if the name is not unique?

> There is a UUID that
> identifies network services, which are related to the network
> interfaces the system configuration service manages, but network
> *services* on OS X are not the same as network *interfaces*, and they
> are not mapped 1:1 to one another.

I'm kind of lost here, sine I don't know the details behind OS X.

Are you arguing tha the discussion of interfae names (or something else)
is incorrect? Are you arguing that there's something that should be
clarified? (if so, what, and how?)

ANy help in this respect will be really welcome.

Thanks!

Best regards,

---

From: james woodyatt <[email-masked]>
Date: Sun, 19 May 2013 15:19:26 -0700

> How do you ifconfig(8) them if the name is not unique?

The names used by ifconfig(8) are temporally unique, but not universally unique, i.e. it is not the case that 'net0' at time t=0.0 ns is the same as 'net0' at time t=0.1 ns.  When they are different, the UUID of the network service associated with the 'net0' interface is different.

> I'm kind of lost here, sine I don't know the details behind OS X.

That's why I'm trying to help.

> ANy help in this respect will be really welcome.

Yes, I'm saying that interface names don't map well to the concept you're expecting them to indicate.  You seem to think that a networking interface interface used with a particular network service will always have the same name every time it is put into service.

That's not the case with OS X, which makes no such guarantee.  Yes, many people labor under the misconception that 'en0' is always the Ethernet port, but we try to disabuse them of that idea every chance we get.  The same thing goes for the interface index.  The only thing that really identifies the interface uniquely is the UUID for the network service that you find in the System Configuration Dynamic Store, but even that may not be good choice for the Net_Iface value here, because services come and go as users make configuration changes and migrate their systems from one operating system release to the next.

Look, the more I think about this issue, the clearer it becomes to me that you just need to change...

>>> o  it MUST be different for each network interface

...to...

>>> o  it MUST be different for each network interface simultaneously in use.

That will leave the OS X system configuration service with sufficient latitude that it can choose a value for each network interface it configures to meet the goals of this specification.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 19 May 2013 20:43:59 -0300

On 05/19/2013 07:19 PM, james woodyatt wrote:
> The names used by ifconfig(8) are temporally unique, but not
> universally unique, i.e. it is not the case that 'net0' at time t=0.0
> ns is the same as 'net0' at time t=0.1 ns.  When they are different,
> the UUID of the network service associated with the 'net0' interface
> is different.

I think that's the case with most systems. e.g., you plug two USB based
wireless cards, A and B, and they become wlan0 an wlan1.You unplug them,
and plug them again but in different order, and A becomes wlan1 and B
becomes wlan0.

>> Are you arguing tha the discussion of interfae names (or something
>> else) is incorrect? Are you arguing that there's something that
>> should be clarified? (if so, what, and how?)
>> 
> Yes, I'm saying that interface names don't map well to the concept
> you're expecting them to indicate.  

Other than the fix you suggested ("it MUST be different for each network
interface simultaneously in use."), is there anything to be fixe in,
say, Appendix A?

> You seem to think that a
> networking interface interface used with a particular network service
> will always have the same name every time it is put into service.

Nop. Please see the discussion of interface names in Appendix A. They
are deemed as rather more constant than interface indexes, but still
might change when interfaces are removed/added.

> That's not the case with OS X, which makes no such guarantee.  Yes,
> many people labor under the misconception that 'en0' is always the
> Ethernet port, but we try to disabuse them of that idea every chance
> we get.  

Just out of curiosity: Do they use a different identifier with ifconfig?
O actually use some other command altogether?

> The same thing goes for the interface index.  The only thing
> that really identifies the interface uniquely is the UUID for the
> network service that you find in the System Configuration Dynamic
> Store, but even that may not be good choice for the Net_Iface value
> here, because services come and go as users make configuration
> changes and migrate their systems from one operating system release
> to the next.

Just ouf of curiosity: are UUIDs attahed to the NIC itself (as e.g. the
MAC address)? Can they vary upon installation/removal of network interfaces?

>>>> simultaneously in use.
> That will leave the OS X system configuration service with sufficient
> latitude that it can choose a value for each network interface it
> configures to meet the goals of this specification.

Done. (this change will appear in upcoming version -08 of this document).

Thanks!

Best regards,

---

From: james woodyatt <[email-masked]>
Date: Mon, 20 May 2013 10:33:46 -0700

> interface simultaneously in use."), is there anything to be fixe in,

I don't see why Appendix A needs to comprise an exhaustive list of all possibilities, but it might be improved by the addition of something like this:

  A.4. Logical Network Service Identity

  Host operating systems with a conception of logical network service identity,
  distinct from network interface identity or index, may keep a UUID or similar
  number with the stability properties appropriate for use as the Net_Iface
  parameter.

> [I wrote:]

> O actually use some other command altogether?

The names used by ifconfig(8) on OS X are provided for POSIX compatibility.  The authoritative identity of network services and the interfaces where they are configured is managed by the system configuration daemon (configd).  The schema for that data tends to use UUID for unique identifiers.

> MAC address)? Can they vary upon installation/removal of network interfaces?

The UUID in the SCDynamicStore are always chosen from a random number source.  They may change as a result of user configuration events.  They may change when network interfaces are installed or removed.  They can be used to identify nodes in the System Configuration dynamic and persistent stores, and the natural way to implement the specification in this draft on OS X and iOS would be keep the Net_Iface parameter in the Network Service structure in the SC persistent store.

> Done. (this change will appear in upcoming version -08 of this document).

Awesome.  Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 20 May 2013 23:00:48 -0300

Hi, James,

On 05/20/2013 02:33 PM, james woodyatt wrote:
>> 
>> Other than the fix you suggested ("it MUST be different for each
>> network interface simultaneously in use."), is there anything to be
>> fixe in, say, Appendix A?
> 
> I don't see why Appendix A needs to comprise an exhaustive list of
> all possibilities, but it might be improved by the addition of
> something like this:
> 
> Host operating systems with a conception of logical network service
> identity, distinct from network interface identity or index, may keep
> a UUID or similar number with the stability properties appropriate
> for use as the Net_Iface parameter.

Thanks for the text! I'll incorporate it in th next rev.

Question: Is there any reference I could provide about "logical network
service identity"? (even a manpage would be okay...) -- I'd use it as:

"Host operating systems with a conception of logical network service
identity (see e.g. [REFERENCE])..."

Additionally, I'd like to better understand the stability properties of
UUIDs (and add some text about it right after the text that you have
suggested). My assumption is that one would have UUIDs for network
interfaces that would, at least, be constant across system bootstrap
sequences? (that would be something not yet present in OS X now, but
that could be added as part of the implementation of this specification?)

P.S.: Thanks for educating me about the OS X internals!

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 May 2013 18:32:33 -0300

Hi, Ben,

On 05/21/2013 06:05 PM, Ben Campbell wrote:
> I'm not sure my last set of comments got to you; I kept getting email
> bounces. In any case, this version addressed all but one of my
> comments:
> 
> -- section 3, paragraphs starting with "The Interface_ID [Now
> Net_Iface] is a value..."
> 
> You say the following properties are "desirable", but then go on to
> state them with MUSTs in the following bullet points. This is
> ambiguous. If they are only "desirable properties", then the
> normative language is not appropriate. If you mean the MUSTs, then
> these are _requirements_.

Agreed. For instance, Karl Auer reported this one a couple of days ago.
I'll be s/desired/required/ in the upcoming -08 version.

Thanks so much!

Best regards,

---

From: Ben Campbell <[email-masked]>
Date: Tue, 21 May 2013 16:05:01 -0500

(resending to include Gen-ART and 6man lists at Fernando's request)

Hi Fernando,

I'm not sure my last set of comments got to you; I kept getting email bounces. In any case, this version addressed all but one of my comments:

-- section 3, paragraphs starting with "The Interface_ID [Now Net_Iface] is a value..."

You say the following properties are "desirable", but then go on to state them with MUSTs in the following bullet points. This is ambiguous. If they are only "desirable properties", then the normative language is not appropriate. If you mean the MUSTs, then these are _requirements_.

Thanks!

Ben.

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 May 2013 09:50:29 +0100

> that could be added as part of the implementation of this specification?)

Hi Fernando, you may wish to look at RFC 6355 about that and similar issues.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Sat, 01 Jun 2013 00:19:30 +0200

Hi, Tim,

> Hi Fernando, you may wish to look at RFC 6355 about that and similar issues.

FWIW, I've referenced RFC4122, which seems to be a more general document
on UUIDs (I got the reference to RFC4122 in RFC6355 :-) )

Thanks s much!

Best regards,