Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (4)

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Mar 2011 17:56:41 -0600

On Jan 10, 2011, at 5:17 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> More comments:
> 
> A.30. Section 5.5.4.1 "opaque config_data<0..2^24-1>"
> 
> If a configuration document contains multiple configuration elements (and I
> guess multiple matching signature elements), then should not config_data been in
> fact structured the same way than kinds?, i.e. an XML fragment containing only
> the configuration element and the signature element for this overlay, extracted
> from the multiple configuration elements document?
> 
> See also A.31 below.
> 
> A.31. Section 1.1 'The file can contain multiple "configuration" elements..."
> 
> This contradicts the RELAX NG grammar in section 10.1.1.  In addition, should
> not configuration elements be structured as kind elements are, i.e. something
> like this:
> 
> <overlay>
>  <configuration-block>
>    <configuration>...</configuration>
>    <signature>...</signature>
>  </configuration-block>
>  <configuration-block>
>    <configuration>...</configuration>
>    <signature>...</signature>
>  </configuration-block>
> </overlay>
> 
> In this case, config_data would contain a XML configuration-block production
> (see A.31 above)

I changed the grammar to allow

> <overlay>
> 
>    <configuration>...</configuration>
>    <signature>...</signature>
> 
>    <configuration>...</configuration>
>    <signature>...</signature>
> 
> </overlay>

I like the config-block would be better but it would break existing stuff so I made the grammar match the existing text which seemed to allow the above. Thoughts on what we should do here? I have no strong opinion - fundamentally they are both about the same. 

> 
> A.32. Section 10.1 "root-cert: [...] there can be more than one root-cert element"
> 
> This contradicts the RELAX NG grammar in section 10.1.1.

fixed

> 
> A.33. Section 10.1 "enrollment-server: [...] there can be more than one
> enrollment-server element"
> 
> This contradicts the RELAX NG grammar in section 10.1.1.

fixed

> 
> A.34. Section 10.1 'multicast-bootstrap: [...] it has an attribute called
> "address" [...] and an attribute called "port"'
> 
> This contradicts the RELAX NG grammar in section 10.1.1 (hostPort).

fixed 

> 
> A.35. Section 10.1.1 "parameter &= element required-kinds { kind-block* }"
> 
> Because the text in section 10.1. says that "[i]nside each overlay element, the
> required-kinds element can also occur", I think it should be this instead:
> 
> parameter &= element required-kinds { kind-block+ }?
> 
fixed 

> - -- 
> Marc Petit-Huguenin
> Personal email: [email-masked]
> Professional email: [email-masked]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAk0roZgACgkQ9RoMZyVa61fN/wCcCZk9KcSDiVZz2u4E+KVfl2Es
> w3oAoIYvjgqZv3Lwwt73VSRA03uSlFrg
> =/1lC
> -----END PGP SIGNATURE-----
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Mar 2011 09:51:49 -0700

>> I like the config-block would be better but it would break existing stuff so I made the grammar match the existing text which seemed to allow the above. Thoughts on what we should do here? I have…

Having no config-block makes this fragment valid:

<overlay>
  <configuration />
  <configuration />
  <configuration />
  <signature />
  <signature />
</overlay>

But in fact I am withdrawing my suggestion in A.30 to use the config-block in
the ConfigUpdateReq, instead of the whole overlay:  There is nothing that
prevent an implementation to send a document with only one configuration and
signature element in the ConfigUpdateReq, even if the document retrieved from
the configuration server contains more than one.

So my suggestion would be to keep thing as they are, but add text that explain
the configuration/signature elements should be interleaved and that a signature
element applies only to the configuration element immediately preceding.
Perhaps enforcing this in the RelaxNG schema could also be a good thing.

- -- 
Marc Petit-Huguenin