January 2008 - glue-wg - lists.ogf.org

EGEE report on authz
by Burke, S (Stephen) 23 Jan '08

23 Jan '08

Hi, This is the report about the development of authz in EGEE, which has some implications for how we represent VOMS information in GLUE. https://edms.cern.ch/document/887174/1 Stephen

1 0

Telecon reminder - today 3 PM GMT
by Sergio Andreozzi 23 Jan '08

23 Jan '08

Hi everybody, in 30' we have our GLUE telecon: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… for the calling details, Balazs asked to try the SIP-based system (traditional phones supported as well). We'll make a trial and if the quality is not acceptable we fallback to CERN telecon system. See the agenda page for more details. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

Draft version of "undefined values" appendix
by Paul Millar 22 Jan '08

22 Jan '08

Hi all, Here is the draft version of the appendix. I've tried to incorporate the comments made at the last meeting, cut down the word-count slightly and changed several mentions of "illegal" to "undefined". Cheers, Paul. Appendix D : place-holder values for unknown data. ---- Introduction --- Whilst people endeavor to provide accurate information, there may be situations where specific GLUE values may be assigned place-holder (or dummy) values. These place-holder values carry some additional semantic meaning; specifically, that the correct value is currently unknown and the presented value should be ignored. This appendix describes a recommended set of place-holder values to use. GLUE makes no requirement on how much data is published and renderings (of GLUE Schema into concrete type, such as LDAP) may allow publishing of partial information. However, there may be situations where a value is provided that should not be considered valid. Two likely scenarios are discussed below, although others may exist. To avoid confusion, these values have be chosen so they are unlikely to occur under normal operation, whilst still being valid values. Wherever possible, best-practice has been followed. It is not a requirement to use place-holder values in general or to use these values in particular; however, if place-holder values are used, using these values increases the likelihood that others will understand that the value are to be ignored. Use-cases: --- Scenario 1. a static value has no good default value and has not been configured for a particular site. Some provisions for GLUE Schema provide templates. These templates may contain static values that have no good default value; for example, a value might require some detailed knowledge of a site. Whilst there may be the expectation that value be configured it is possible that this did not happen, so exposing the application's default configuration. Scenario 2. information provider is unable to obtain a dynamic value. A dynamic value is provided by an information provider by querying the underlying grid resources. This query will use a number of ancillary resources (e.g., DNS, network hardware) that might fail; the grid services might also fail. If the system collecting the information requires a value, a place-holder will be required. Place-holder values: --- This section describes a number of values that can be represented within a given address space (e.g., UTF-8, Integers, FQDNs, IPv4 address space). Each of the different types are introduced along with the proposed value and a brief discussion on the rational and any other considerations. 1. Simple strings (ASCII/UTF-8) should use "UNDEFINEDVALUE". Upper-case letters make it easier to spot and a single word avoids any white-space issues. This is a default option for strings that have no widely-known structure. If a value is of a more restrictive sub-type (e.g. FQDNs, FQANs), then the rules for more restrictive form should be used. 2. Fully qualified domain names: should use a hostname ending either "example.org" or "example.com" for scenario 1, or "invalid" for scenario 2. RFC 2606 reserves the ".invalid" Top-Level-Domain (TLD) as always invalid and clearly so. For dynamic information a value of "unknown.invalid." may be used. If an alternative is used, it should use the TLD ".invalid". RFC 2606 also defines the ".example" TLD and the two second-level domains: "example.org" and "example.com". These domains have the advantage of ending with a recognisable TLD, so are more immediately recognisable as a DNS name. Default configuration should use DNS names that end ".example.com" or ".example.org" 3. IPv4 addr: should use 192.0.2.250 There are several portions of IPv4 addresses that should not appear on a network, but none that are reserved for a non-existent address. Using an arbitrary address leads to the risk of side-effects. The best option is an IP address from the 192.0.2.0/24 subnet. This subnet is defined in RFC 3330 as "TEST-NET" for use in documentation and example code. Although any IPv4 address from 192.0.2.0/24 may be used, the recommended address above should use for consistency. 5. IPv6 addr: should use 2001:DB8::FFFF There is no documented undefined IPv6 address. RFC 3849 reserves the address prefix 2001:DB8::/32 for documentation. For consistency, the address SHOULD BE the one noted above. 6. Counting/Natural numbers: should use 0 Counting- (also known as Natural-) numbers exclude the number zero, so information provider may use this value to indicate an undefined value. Some counting-number metrics include 0 as a valid value. If so, the metric should be considered an Integer and zero not be used. 7. Integers: should use MAXINT (maximum value representable in the domain). For int32 this is 2,147,483,647 " uint32 this is 4,294,967,295 " int64 this is 9,223,372,036,854,775,807 " uint64 this is 18,446,744,073,709,551,615 For non-negative integers, all numbers expressible within the encoding (int32/uint32/etc...) are valid so there is no safe choice. Although any value may be chosen, perhaps the value least likely to be encountered in any given domain is that domain's maximum value. If an unsigned integer is encoded as a signed integer, it is possible to use negative numbers safely. However, these numbers will be unrepresentable if the number is stored as an unsigned integer. For values that might be a positive, zero or a negative integer, all numbers expressible within the encoding (unsigned int) are valid so there is no safe choice. For consistency, the MAXINT value should be used. Information providers should not attempt to conveying further semantic distinction, for example by using more than one "undefined" number. 8. Filenames: should be "UNDEFINEDPATH". As with the simple string, a single upper-case word is recommended. 9. Uniform Resource Identifier (URI): schema-specific RFC 3986 defines URIs as a "federated and extensible naming system." All URIs start with a schema-name part and no schema-name has been reserved for undefined or example values. For any given URI schema ("http", for example), it may be possible to define an undefined value within that name-space. If a GLUE value has only one valid schema, the undefined value should be taken from that schema. If several schemata are possible, one should be chosen from the available options, which should be the most commonly used. For schemata that include a FQDN (e.g., a reference to an Internet host), an undefined value should be derived by using an undefined FQDN in an otherwise valid URI. See above for details on undefined FQDNs. Examples of such schemata include: http, httpg and mailto. For other schemata, some element of the naming system should indicate that the value is undefined. This is subject to further work. 10. X509 Distinguished Names: should include a RDN of CN=UNDEFINEDUSER Rational: X509 uses a X500 namespace, represented as several RDNs concatenated by commas. The final RDN is usually a single common name (CN). It is possible for more than one CN to be present, allowing inclusion of additional semantic meaning. However, this is outwith the scope of the document. Definition of words: --- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are used deliberately and take their meaning from RFC 2119. A brief summary is given here. 1. MUST (or "REQUIRED" or "SHALL") means that no deviation is allowed from conforming software. 2. MUST NOT (or "SHALL NOT") means complete prohibition of this behaviour with conforming software. 3. SHOULD (or "RECOMMENDED") means that there may be reasons why conforming software does not to adopt this behaviour, but all the effects of an alternative behaviour must be understood and considered before choosing a different course. 4. SHOULD NOT (or "NOT RECOMMENDED") means that there may be reasons why conforming software adopts this behaviour, but all the effects of an alternative behaviour must be understood and considered before choosing a different course. 5. MAY (or "OPTIONAL") means an item is completely optional.

1 0

first draft schedule - GLUE sessions at OGF 22
by Sergio Andreozzi 22 Jan '08

22 Jan '08

Dear all, I just found out that the OGF22 schedule was updated with the requested GLUE sessions: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/Participatio… at the moment, all three sessions are scheduled in the same day. I would like to ask to postpone the no.3 or anticipate no.1 by one day if you have no particular constraints. By the way, could you please confirm if you will attend/not attend the next OGF? Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

6 5

GLUE telecon reminder
by Sergio Andreozzi 21 Jan '08

21 Jan '08

Dear all, this is to reming about our coming telecons for this week: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… (two telecons) http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… (one telecon) http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… (one telecon) for your convenience, from now on the telecon schedule will also be available in a public google calendar so that you can register to it: http://www.google.com/calendar/embed?src=lnhn02nb0qp67a454g6j2hnflk%40group… talking to you tomorrow, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

Updated Use Case Document
by Laurence 21 Jan '08

21 Jan '08

I have updated the Use Case document with all the comments that I have received. http://forge.gridforum.org/sf/go/doc14621 The Glossary and Reference still needs to be done but I will do that when the document is finalized. Laurence

3 2

express attendance for telecon - week 21-25/1
by Sergio Andreozzi 18 Jan '08

18 Jan '08

Dear all, please, express your attendance to the proposed GLUE telecons for next week: http://www.doodle.ch/participation.html?pollId=sv9ynb5w42vfuy5d Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

today telecon canceled - moved to next week
by Sergio Andreozzi 18 Jan '08

18 Jan '08

Dear all, since both Balazs and Paul will not be able to attend, we decide to move the telecon to next week, 23/1. Summarizing, next week we have (rich) plans for: 22/1, 1 PM GMT: AustralianGrid reqs 23/1, 3 PM GMT: Computing 24/1, 3 PM GMT: implementations if people can afford, we could discuss progress on storage entities, e.g. 22/1 3 PM GMT I will send you a doodle survey for expressing the preferences. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0

GLUE 2.0 - draft 19 - spec + XSD
by Sergio Andreozzi 18 Jan '08

18 Jan '08

Dear all, based on the yesterday telecon, here is the new update: 1. GLUE 2.0 Spec - draft 19 including yesterday request for changes http://forge.ogf.org/sf/docman/do/viewDocument/projects.glue-wg/docman.root… 2. GLUE 2.0 XSD rendering + example (link available in this page) http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE2XMLSche… tomorrow we have a telecon. Please, comment on the tentative agenda (i.e., if there are updates on the artifacts, we can go for them otherwise we start revision of other computing entities definitions): http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

2 3

GLUE Telecon reminder - today 18/1 - 3 PM GMT
by Sergio Andreozzi 18 Jan '08

18 Jan '08

Dear all, this is a gentle reminder for our today telecon: http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/PhoneMeeting… Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi

1 0